#
9ba51579 |
| 07-Aug-2018 |
Leonard Mosescu <mosescu@google.com> |
Misc module/dwarf logging improvements
This change improves the logging for the lldb.module category to note a few interesting cases:
1. Local object file found, but specs not matching 2. Local obj
Misc module/dwarf logging improvements
This change improves the logging for the lldb.module category to note a few interesting cases:
1. Local object file found, but specs not matching 2. Local object file not found, using a placeholder module
The handling and logging for the cases wehre we fail to load compressed dwarf symbols is also improved.
Differential Revision: https://reviews.llvm.org/D50274
llvm-svn: 339161
show more ...
|
#
0c679b71 |
| 06-Aug-2018 |
Stephane Sezer <sas@cd80.net> |
Revert "Add a relocation for R_AARCH64_ABS32 in ObjectFileELF"
This reverts commit f055ce7eb893cd0d17ebcfd4125018f46f983aff.
llvm-svn: 339071
|
#
b015ca6f |
| 06-Aug-2018 |
Stephane Sezer <sas@cd80.net> |
Add a relocation for R_AARCH64_ABS32 in ObjectFileELF
Summary: .rela.debug_info relocations are being done via ObjectFileELF::ApplyRelocations for aarch64. Currently, the switch case that iterates o
Add a relocation for R_AARCH64_ABS32 in ObjectFileELF
Summary: .rela.debug_info relocations are being done via ObjectFileELF::ApplyRelocations for aarch64. Currently, the switch case that iterates over the relocation type is only implemented for a few different types and `assert(false)`es over the rest.
Implement the relocation for R_AARCH64_ABS32 in ApplyRelocations
Reviewers: sas, xiaobai, peter.smith, clayborg, javed.absar, espindola
Differential Revision: https://reviews.llvm.org/D49407
Change by Nathan Lanza <lanza@fb.com>
llvm-svn: 339068
show more ...
|
Revision tags: llvmorg-7.0.0-rc1 |
|
#
77c397f4 |
| 29-Jun-2018 |
Pavel Labath <labath@google.com> |
UUID: Add support for arbitrary-sized module IDs
Summary: The data structure is optimized for the case where the UUID size is <= 20 bytes (standard length emitted by the GNU linkers), but larger siz
UUID: Add support for arbitrary-sized module IDs
Summary: The data structure is optimized for the case where the UUID size is <= 20 bytes (standard length emitted by the GNU linkers), but larger sizes are also possible.
I've modified the string conversion function to support the new sizes as well. For standard UUIDs it maintains the traditional formatting (4-2-2-2-6). If a UUID is shorter, we just cut this sequence short, and for longer UUIDs it will just repeat the last 6-byte block as long as necessary.
I've also modified ObjectFileELF to take advantage of the new UUIDs and avoid manually padding the UUID to 16 bytes. While there, I also made sure the computed UUID does not depend on host endianness.
Reviewers: clayborg, lemo, sas, davide, espindola
Subscribers: emaste, arichardson, lldb-commits
Differential Revision: https://reviews.llvm.org/D48633
llvm-svn: 335963
show more ...
|
#
2f93fd1f |
| 26-Jun-2018 |
Pavel Labath <labath@google.com> |
Represent invalid UUIDs as UUIDs with length zero
Summary: During the previous attempt to generalize the UUID class, it was suggested that we represent invalid UUIDs as length zero (previously, we u
Represent invalid UUIDs as UUIDs with length zero
Summary: During the previous attempt to generalize the UUID class, it was suggested that we represent invalid UUIDs as length zero (previously, we used an all-zero UUID for that). This meant that some valid build-ids could not be represented (it's possible however unlikely that a checksum of some file would be zero) and complicated adding support for variable length build-ids (should a 16-byte empty UUID compare equal to a 20-byte empty UUID?).
This patch resolves these issues by introducing a canonical representation for an invalid UUID. The slight complication here is that some clients (MachO) actually use the all-zero notation to mean "no UUID has been set". To keep this use case working (while making it very explicit about which construction semantices are wanted), replaced the UUID constructors and the SetBytes functions with named factory methods. - "fromData" creates a UUID from the given data, and it treats all bytes equally. - "fromOptionalData" first checks the data contents - if all bytes are zero, it treats this as an invalid/empty UUID.
Reviewers: clayborg, sas, lemo, davide, espindola
Subscribers: emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D48479
llvm-svn: 335612
show more ...
|
#
04803b3e |
| 26-Jun-2018 |
Tatyana Krasnukha <tatyana@synopsys.com> |
Change AddressClass type from 'enum' to 'enum class'.
If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler.
Change AddressClass type from 'enum' to 'enum class'.
If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa.
llvm-svn: 335599
show more ...
|
Revision tags: llvmorg-6.0.1, llvmorg-6.0.1-rc3 |
|
#
ad8d48f9 |
| 13-Jun-2018 |
Jonas Devlieghere <jonas@devlieghere.com> |
[FileSpec] Delegate common operations to llvm::sys::path
With the recent changes in FileSpec to use LLVM's path style, it is possible to delegate a bunch of common path operations to LLVM's path hel
[FileSpec] Delegate common operations to llvm::sys::path
With the recent changes in FileSpec to use LLVM's path style, it is possible to delegate a bunch of common path operations to LLVM's path helpers. This means we only have to maintain a single implementation and at the same time can benefit from the efforts made by the rest of the LLVM community.
This is part one of a set of patches. There was no obvious way to split this so I just worked from top to bottom.
Differential revision: https://reviews.llvm.org/D48084
llvm-svn: 334615
show more ...
|
Revision tags: llvmorg-6.0.1-rc2 |
|
#
a041d848 |
| 01-Jun-2018 |
Pavel Labath <labath@google.com> |
Add .debug_names section glue code
llvm-svn: 333743
|
#
1e6a01fc |
| 12-May-2018 |
Davide Italiano <davide@freebsd.org> |
Revert "[LLDB] Support GNU-style compressed debug sections (.zdebug)"
This reverts commit r332162 as it breaks the bots (Ubuntu 14.04) with the following message:
Build Command Output: objcopy: opt
Revert "[LLDB] Support GNU-style compressed debug sections (.zdebug)"
This reverts commit r332162 as it breaks the bots (Ubuntu 14.04) with the following message:
Build Command Output: objcopy: option '--compress-debug-sections' doesn't allow an argument
llvm-svn: 332165
show more ...
|
#
56ab68f3 |
| 12-May-2018 |
Davide Italiano <davide@freebsd.org> |
[LLDB] Support GNU-style compressed debug sections (.zdebug)
Patch by Erik Welander!
Differential Revision: https://reviews.llvm.org/D45628
llvm-svn: 332162
|
#
2550ca1e |
| 08-May-2018 |
Greg Clayton <gclayton@apple.com> |
Add support to object files for accessing the .debug_types section
In an effort to make the .debug_types patch smaller, breaking out the part that reads the .debug_types from object files into a sep
Add support to object files for accessing the .debug_types section
In an effort to make the .debug_types patch smaller, breaking out the part that reads the .debug_types from object files into a separate patch
Differential Revision: https://reviews.llvm.org/D46529
llvm-svn: 331777
show more ...
|
#
d8f460e8 |
| 02-May-2018 |
Adrian Prantl <aprantl@apple.com> |
Enable AUTOBRIEF in doxygen configuration.
This brings the LLDB configuration closer to LLVM's and removes visual clutter in the source code by removing the @brief commands from comments.
This patc
Enable AUTOBRIEF in doxygen configuration.
This brings the LLDB configuration closer to LLVM's and removes visual clutter in the source code by removing the @brief commands from comments.
This patch also reflows the paragraphs in all doxygen comments.
See also https://reviews.llvm.org/D46290.
Differential Revision: https://reviews.llvm.org/D46321
llvm-svn: 331373
show more ...
|
#
05097246 |
| 30-Apr-2018 |
Adrian Prantl <aprantl@apple.com> |
Reflow paragraphs in comments.
This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to r
Reflow paragraphs in comments.
This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue
if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2)
continue
if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
show more ...
|
#
edb01276 |
| 30-Apr-2018 |
Pavel Labath <labath@google.com> |
ObjectFileELF: Add support for arbitrarily named code sections
ObjectFileELF assumes that code section has ".text" name. There is an exception for kalimba toolchain that can use arbitrary names, but
ObjectFileELF: Add support for arbitrarily named code sections
ObjectFileELF assumes that code section has ".text" name. There is an exception for kalimba toolchain that can use arbitrary names, but other toolchains also could use arbitrary names for code sections. For example, corert uses separate section for compiled managed code. As lldb doesn't recognize such section it leads to problem with breakpoints on arm, because debugger cannot determine instruction set (arm/thumb) and uses incorrect breakpoint opcode that breaks program execution.
This change allows debugger to correctly handle such code sections. We assume that section is a code section if it has SHF_EXECINSTR flag set and has SHT_PROGBITS type.
Patch by Konstantin Baladurin <k.baladurin@partner.samsung.com>. Differential Revision: https://reviews.llvm.org/D44998
llvm-svn: 331173
show more ...
|
#
e4777a9d |
| 29-Apr-2018 |
Jan Kratochvil <jan.kratochvil@redhat.com> |
Support reading section ".gnu_debugaltlink"
Differential revision: https://reviews.llvm.org/D40468
llvm-svn: 331148
|
Revision tags: llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2 |
|
#
16064d35 |
| 20-Mar-2018 |
Pavel Labath <labath@google.com> |
Re-land: [lldb] Use vFlash commands when writing to target's flash memory regions
The difference between this and the previous patch is that now we use ELF physical addresses only for loading object
Re-land: [lldb] Use vFlash commands when writing to target's flash memory regions
The difference between this and the previous patch is that now we use ELF physical addresses only for loading objects into the target (and the rest of the module load address logic still uses virtual addresses).
Summary: When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup.
- Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address. - Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications - Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region
Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: llvm-commits, arichardson, emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42145 Patch by Owen Shaw <llvm@owenpshaw.net>.
llvm-svn: 327970
show more ...
|
Revision tags: llvmorg-5.0.2-rc1 |
|
#
3ef4eebc |
| 09-Mar-2018 |
Pavel Labath <labath@google.com> |
[elf] Remove one copy of the section merging code
Summary: Besides being superfluous, this double merging was actually wrong and causing some sections to be added twice. The reason for that was that
[elf] Remove one copy of the section merging code
Summary: Besides being superfluous, this double merging was actually wrong and causing some sections to be added twice. The reason for that was that the code assumes section IDs are unique in the section list, but this is only true if all sections in the list come from the same object file.
Reviewers: fjricci, jankratochvil
Subscribers: emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D44157
llvm-svn: 327123
show more ...
|
Revision tags: llvmorg-6.0.0 |
|
#
ec03d7e3 |
| 28-Feb-2018 |
Pavel Labath <labath@google.com> |
Revert "[lldb] Use vFlash commands when writing to target's flash memory regions"
This reverts commit r326261 as it introduces inconsistencies in the handling of load addresses for ObjectFileELF --
Revert "[lldb] Use vFlash commands when writing to target's flash memory regions"
This reverts commit r326261 as it introduces inconsistencies in the handling of load addresses for ObjectFileELF -- some parts of the class use physical addresses, and some use virtual. This has manifested itself as us not being able to set the load address of the vdso "module" on android.
llvm-svn: 326367
show more ...
|
#
029fb693 |
| 27-Feb-2018 |
Pavel Labath <labath@google.com> |
[lldb] Use vFlash commands when writing to target's flash memory regions
Summary: When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write
[lldb] Use vFlash commands when writing to target's flash memory regions
Summary: When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup.
- Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address. - Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications - Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region
Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: arichardson, emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42145 Patch by Owen Shaw <llvm@owenpshaw.net>
llvm-svn: 326261
show more ...
|
Revision tags: llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2 |
|
#
4f033125 |
| 05-Feb-2018 |
Pavel Labath <labath@google.com> |
Fix parsing of object files with "early" section headers
ObjectFileELF::GetModuleSpecifications contained a lot of tip-toing code which was trying to avoid loading the full object file into memory.
Fix parsing of object files with "early" section headers
ObjectFileELF::GetModuleSpecifications contained a lot of tip-toing code which was trying to avoid loading the full object file into memory. It did this by trying to load data only up to the offset if was accessing. However, in practice this was useless, as 99% of object files we encounter have section headers at the end, so we would load the whole file as soon as we start parsing the section headers.
In fact, this would break as soon as we encounter a file which does *not* have section headers at the end (yaml2obj produces these), as the access to .strtab (which we need to get the section names) was not guarded by this offset check.
As this strategy was completely ineffective anyway, I do not attempt to proliferate it further by guarding the .strtab accesses. Instead I just lead the full file as soon as we are reasonably sure that we are indeed processing an elf file.
If we really care about the load size here, we would need to reimplement this to just load the bits of the object file we need, instead of loading everything from the start of the object file to the given offset. However, given that the OS will do this for us for free when using mmap, I think think this is really necessary.
For testing this I check a (tiny) SO file instead of yaml2obj-ing it because the fact that they come out first is an implementation detail of yaml2obj that can change in the future.
llvm-svn: 324254
show more ...
|
#
c561a6a9 |
| 30-Jan-2018 |
Pavel Labath <labath@google.com> |
Add LLDB_LOG_ERROR macro
Summary: The difference between this and regular LLDB_LOG is that this one clears the error object unconditionally. This was inspired by the ObjectFileELF bug (r322664), wh
Add LLDB_LOG_ERROR macro
Summary: The difference between this and regular LLDB_LOG is that this one clears the error object unconditionally. This was inspired by the ObjectFileELF bug (r322664), where the error object was being cleared only if logging was enabled.
Reviewers: davide, zturner, jingham, clayborg
Subscribers: lldb-commits, emaste
Differential Revision: https://reviews.llvm.org/D42182
llvm-svn: 323753
show more ...
|
Revision tags: llvmorg-6.0.0-rc1 |
|
#
b424de39 |
| 17-Jan-2018 |
Pavel Labath <labath@google.com> |
Fix assertion in ObjectFileELF
In D40616 I (mistakenly) assumed that logging an llvm::Error would clear it. This of course is only true if logging is actually enabled.
This fixes the assertion by m
Fix assertion in ObjectFileELF
In D40616 I (mistakenly) assumed that logging an llvm::Error would clear it. This of course is only true if logging is actually enabled.
This fixes the assertion by manually clearing the error, but it raises the point of whether we need a special error-clearing logging primitive.
llvm-svn: 322664
show more ...
|
#
50251fc7 |
| 21-Dec-2017 |
Pavel Labath <labath@google.com> |
Make sure DataBufferLLVM contents are writable
Summary: We sometimes need to write to the object file we've mapped into memory, generally to apply relocations to debug info sections. We've had that
Make sure DataBufferLLVM contents are writable
Summary: We sometimes need to write to the object file we've mapped into memory, generally to apply relocations to debug info sections. We've had that ability before, but with the introduction of DataBufferLLVM, we have lost it, as the underlying llvm class (MemoryBuffer) only supports read-only mappings.
This switches DataBufferLLVM to use the new llvm::WritableMemoryBuffer class as a back-end, as this one guarantees to return a writable buffer.
This removes the need for the "Private" flag to the DataBufferLLVM creation functions, as it was really used to mean "writable". The LLVM function also does not have the NullTerminate flag, so I've modified our clients to not require this feature and removed that flag as well.
Reviewers: zturner, clayborg, jingham
Subscribers: emaste, aprantl, arichardson, krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D40079
llvm-svn: 321255
show more ...
|
#
4c2eb8b2 |
| 15-Dec-2017 |
Pavel Labath <labath@google.com> |
Fix 32-bit builds broken by 320813
cast to size_t to avoid narrowing error.
llvm-svn: 320816
|
#
e2867bc4 |
| 15-Dec-2017 |
Pavel Labath <labath@google.com> |
ObjectFileELF: Add support for compressed sections
Summary: We use the llvm decompressor to decompress SHF_COMPRESSED sections. This enables us to read data from debug info sections, which are somet
ObjectFileELF: Add support for compressed sections
Summary: We use the llvm decompressor to decompress SHF_COMPRESSED sections. This enables us to read data from debug info sections, which are sometimes compressed, particuarly in the split-dwarf case. This functionality is only available if llvm is compiled with zlib support.
Reviewers: clayborg, zturner
Subscribers: emaste, mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D40616
llvm-svn: 320813
show more ...
|