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
These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall code layering (although it still does not break any particular
dependency completely).
The XCode project will need to be updated after this change.
Differential Revision: https://reviews.llvm.org/D49740
llvm-svn: 339127
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
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
This change allows to make AddressClass strongly typed enum and not to have issues with old versions of SWIG that don't support enum classes.
llvm-svn: 335710
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
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
This method does one of two things:
1. finds a minimum os deployment version # in a Mach-O load
command and saves the three parts in the m_sdk_version, or
2. finds no valid min os version # load command, pushes a
sentinel value on the m_sdk_version vector so we don't search
the same load commands multiple times.
There was a little bug when we found a load command with
a version of 0.0.0 - the method would not add anything to
the m_sdk_version vector but would declare that a success.
It would not push the sentinel value to the vector.
There was code later in the method which assumed that
the vector always had a sentinel value, at least, and that
code could crash when this method was called back when
evaluating a Swift expression. (these version #'s are
fetched lazily so it wouldn't happen when the object file
was parsed, only when doing an expression that needed
the version #).
<rdar://problem/41372699>
llvm-svn: 335556
Summary:
This has multiple advantages:
- we need only one function argument/instance variable instead of three
- no need to default initialize variables
- no custom parsing code
- VersionTuple has comparison operators, which makes version comparisons much
simpler
Reviewers: zturner, friss, clayborg, jingham
Subscribers: emaste, lldb-commits
Differential Revision: https://reviews.llvm.org/D47889
llvm-svn: 334950
SetFile has an optional style argument which defaulted to the native
style. This patch makes that argument mandatory so clients of the
FileSpec class are forced to think about the correct syntax.
At the same time this introduces a (protected) convenience method to
update the file from within the FileSpec class that keeps the current
style.
These two changes together prevent a potential pitfall where the style
might be forgotten, leading to the path being updated and the style
unintentionally being changed to the host style.
llvm-svn: 334663
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
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
Getting the deployment target can be significant information when
rebuilding clang modules since availability information could depend
on it.
rdar://problem/40039633
Differential Revision: https://reviews.llvm.org/D46669
llvm-svn: 332067
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
when it and the inferior process both have the same shared cache
(a conglomeration of all libraries at the same fixed address for
all processes), lldb will read data out of its own memory to speed
things up. The shared cache has a UUID, so lldb currently checks
that the UUID of its own shared cache matches that of the inferior.
This change adds one refinement to that -- it checks that the UUID
is the same and that the base address of the shared cache is the
same. And only uses its local shared cache if they are both identical.
This involved using a different style of SPI with dyld to get lldb's
shared cache load address, but it's not especially difficult.
One unattractive part of the change is that I'm using the real
underlying types of task_t and kern_return_t instead of picking
them up from mach/mach.h. The defines that get picked up there (a
lot from machine.h but others too) conflict with llvm/Support/MachO.h
even when I have mach.h included before our SafeMachO.h which
undefines most of the defines before including llvm/Support/MachO.h.
I'll need to augment the #undefs in SafeMachO.h to get this to
compile cleanly, but that'll be another day.
<rdar://problem/39868238>
llvm-svn: 331497
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
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
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
Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed.
Differential Revision: https://reviews.llvm.org/D45977
llvm-svn: 331049
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
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
Summary:
In an effort to understand the function's operation, I've split it into logical
pieces. Parsing of a single segment is moved to a separate function (and the
parsing state that is carried from one segment to another is explicitly
captured in the SegmentParsingContext object). I've also extracted some pieces
of code which were already standalone (validation of the segment load command,
determining the section type, determining segment permissions) into
separate functions.
Parsing of a single section within the segment should probably also be a
separate function, but I've left that for a separate patch.
This patch is intended to be NFC.
Reviewers: clayborg, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D44074
llvm-svn: 326791
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
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
SPI call to to find its own shared cache's UUID. On newer sytems we
need to use the a new SPI which will return the UUID directly.
<rdar://problem/36625871>
llvm-svn: 324437
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
This patch is the result of a discussion on lldb-dev, see
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013111.html for
background.
For each test (should be eventually: each test configuration) a
separate build directory is created and we execute
make VPATH=$srcdir/path/to/test -C $builddir/path/to/test -f $srcdir/path/to/test/Makefile -I $srcdir/path/to/test
In order to make this work all LLDB tests need to be updated to find
the executable in the test build directory, since CWD still points at
the test's source directory, which is a requirement for unittest2.
Although we have done extensive testing, I'm expecting that this first
attempt will break a few bots. Please DO NOT HESITATE TO REVERT this
patch in order to get the bots green again. We will likely have to
iterate on this some more.
Differential Revision: https://reviews.llvm.org/D42281
llvm-svn: 323803
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
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
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
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
so it has the same padding as the kernel's definition
which is written in terms of uint128_t. Original patch
by Ryan Mansfield.
<rdar://problem/35468499>
llvm-svn: 318357
break. The alignas(__uint128_t) is not recognized with MSVC
it looks like. Zachary, is there a similar type on windows?
I suppose I can go with alignas(16) here but I'd prefer to
specify the type alignment that I want & let the ABI dictate
how much padding is required.
llvm-svn: 318262
The rationale here is that ArchSpec is used throughout the codebase,
including in places which should not depend on the rest of the code in
the Core module.
This commit touches many files, but most of it is just renaming of
#include lines. In a couple of cases, I removed the #include ArchSpec
line altogether, as the file was not using it. In one or two places,
this necessitated adding other #includes like lldb-private-defines.h.
llvm-svn: 318048
FreeBSD kernel modules are actually relocatable (.o) ELF files and this
previously caused some issues for LLDB. This change addresses these when
using lldb to symbolicate FreeBSD kernel backtraces.
The major problems:
- Relocations were not being applied to the DWARF debug info despite
there being code to do this. Several issues prevented it from working:
- Relocations are computed at the same time as the symbol table, but
in the case of split debug files, symbol table parsing always
redirects to the primary object file, meaning that relocations would
never be applied in the debug file.
- There's actually no guarantee that the symbol table has been parsed
yet when trying to parse debug information.
- When actually applying relocations, it will segfault because the
object files are not mapped with MAP_PRIVATE and PROT_WRITE.
- LLDB returned invalid results when performing ordinary address-to-
symbol resolution. It turned out that the addresses specified in the
section headers were all 0, so LLDB believed all the sections had
overlapping "file addresses" and would sometimes return a symbol from
the wrong section.
Patch by Brian Koropoff
Differential Revision: https://reviews.llvm.org/D38142
llvm-svn: 314672
Summary:
The DWP (DWARF package) format is used to pack multiple dwo files
generated by split-dwarf into a single ELF file to make distributing
them easier. It is part of the DWARFv5 spec and can be generated by
dwp or llvm-dwp from a set of dwo files.
Caviats:
* Only the new version of the dwp format is supported (v2 in GNU
numbering schema and v5 in the DWARF spec). The old version (v1) is
already deprecated but binutils 2.24 still generates that one.
* Combining DWP files with module debugging is not yet supported.
Subscribers: emaste, mgorny, aprantl
Differential Revision: https://reviews.llvm.org/D36062
llvm-svn: 311775
Cast to `const uint8_t *` instead of `uint8_t *` to avoid the warning
from GCC.
EmulationStateARM.cpp:206:34: warning: cast from type 'const void*' to type 'uint8_t* {aka unsigned char*}' casts away qualifiers [-Wcast-qual]
Cast to `const uint32_t *` and the explicitly cast away the const-ness
of the value. This seems pretty sketchy as the `DataExtractor` holds a
const reference to the data. However, this is no worse than before.
ObjectFilePECOFF.cpp:540:78: warning: cast from type 'const uint8_t* {aka const unsigned char*}' to type 'uint32_t* {aka unsigned int*}' casts away qualifiers [-Wcast-qual]
llvm-svn: 308489
Summary:
The classes have no dependencies, and they are used both by lldb and
lldb-server, so it makes sense for them to live in the lowest layers.
Reviewers: zturner, jingham
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34746
llvm-svn: 306682
Leonard Mosescu