The test was being skipped on the Windwos bot because it requires Python
which was silently disabled because of a configuration issue. Now that
the test runs, this fails as expected.
This bit of code is trying to strip everything up to the first colon
from all debug info paths, as dwarf2 recommends this syntax for storing
the compilation host name. However, this code was too eager, and it
ended up stripping the entire compilation directory, if it did not
contain a forward slash (or a "x:\").
Normally this does not matter, as all absolute paths will contain one of
these patterns, but this does not have to be the case in case the debug
info is produced by "clang -fdebug-compilation-dir", which can end up
producing a relative compilation directory with no slashes (this is one
of the techniques for producing "relocatable" debug info).
This ensures that breakpoint command honors the scripting language
passed with `-s`. Currently the argument ignores the actual language and
only uses it to differentiate between lldb and script commands.
Don't create a new lua state on every operation. Share a single state
across the lifetime of the script interpreter. Add simple locking to
prevent two threads from modifying the state concurrently.
D71372 introduced: `Unwind/thread-step-out-ret-addr-check.test` failing on
Fedora 30 Linux x86_64.
[lldb] Add additional validation on return address in 'thread step-out'
https://reviews.llvm.org/D71372
One problem is the underscored `_nonstandard_stub` in the `.s` file but not in
the LLDB command:
(lldb) breakpoint set -n nonstandard_stub
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) process launch
Process 21919 exited with status = 0 (0x00000000)
Process 21919 launched: '/home/jkratoch/redhat/llvm-monorepo-clangassert/tools/lldb/test/Unwind/Output/thread-step-out-ret-addr-check.test.tmp' (x86_64)
(lldb) thread step-out
error: invalid thread
(lldb) _
Another problem is that Fedora Linux has executable stack by default and all
programs indicate non-executable stack by `PT_GNU_STACK`, after fixing the
underscore I was getting:
(lldb) thread step-out
Process 22294 exited with status = 0 (0x00000000)
(lldb) _
A different approach was tried as:
[lldb] Refactor thread-step-out-ret-addr-check test to use .data instead of stack variable
https://reviews.llvm.org/D71789
Differential revision: https://reviews.llvm.org/D71784
Recently there has been some discussion about how we deal with optional
dependencies in LLDB. The approach in LLVM is to make things work out of
the box. If the dependency isn't there, we move on silently.
That's not true for LLDB. Unless you explicitly disable the dependency
with LLDB_ENABLE_*, you'll get a configuration-time error. The
historical reason for this is that LLDB's dependencies have a much
broader impact, think about Python for example which is required to run
the test suite.
The current approach can be frustrating from a user experience
perspective. Sometimes you just want to ensure LLDB builds with a change
in clang.
This patch changes the optional dependencies (with the exception of
Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On,
Off or Auto, with the latter being the default. On and Off behave the
same as today, forcing the dependency to be enabled or disabled. If the
dependency is set to On but is not found, it results in a configuration
time warning. For Auto we detect if the dependency is there and either
enable or disable it depending on whether it's found.
Differential revision: https://reviews.llvm.org/D71306
PS: The reason Python isn't included yet is because it's so pervasive
that I plan on doing that in a separate patch.
Recently there has been some discussion about how we deal with optional
dependencies in LLDB. The approach in LLVM is to make things work out of
the box. If the dependency isn't there, we move on silently.
That's not true for LLDB. Unless you explicitly disable the dependency
with LLDB_ENABLE_*, you'll get a configuration-time error. The
historical reason for this is that LLDB's dependencies have a much
broader impact, think about Python for example which is required to run
the test suite.
The current approach can be frustrating from a user experience
perspective. Sometimes you just want to ensure LLDB builds with a change
in clang.
This patch changes the optional dependencies (with the exception of
Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On,
Off or Auto, with the latter being the default. On and Off behave the
same as today, forcing the dependency to be enabled or disabled. If the
dependency is set to On but is not found, it results in a configuration
time warning. For Auto we detect if the dependency is there and either
enable or disable it depending on whether it's found.
Differential revision: https://reviews.llvm.org/D71306
PS: The reason Python isn't included yet is because it's so pervasive
that I plan on doing that in a separate patch.
This implements a very elementary Lua script interpreter. It supports
running a single command as well as running interactively. It uses
editline if available. It's still missing a bunch of stuff though. Some
things that I intentionally ingored for now are that I/O isn't properly
hooked up (so every print goes to stdout) and the non-editline support
which is not handling a bunch of corner cases. The latter is a matter of
reusing existing code in the Python interpreter.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html
Differential revision: https://reviews.llvm.org/D71234
Previously, if the current function had a nonstandard stack layout/ABI, and had a valid
data pointer in the location where the return address is usually located, data corruption
would occur when the breakpoint was written. This could lead to an incorrectly reported
crash or silent corruption of the program's state. Now, if the above check fails, the command safely aborts.
Differential Revision: https://reviews.llvm.org/D71372
Summary:
Fixes PR41237 - SIGSEGV on call expression evaluation when debugging clang
When linking multiple compilation units that define the same functions,
the functions is merged but their debug info is not. This ignores debug
info entries for functions in a non-executable sections; those are
functions that were definitely dropped by the linker.
Reviewers: spyffe, clayborg, jasonmolenda
Reviewed By: clayborg
Subscribers: labath, aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71487
Create a new test for lldb launched without a script interpreter and
move it under a new `ScriptInterpreter` directory. Also move
crashlog.test there for consistency.
Summary:
Add `function.mangled-name` key for FormatEntity to show the mangled
function names in backtraces.
rdar://54088244
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71237
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Summary:
This enables us to display the contents of atomic structs. Calling the
removal of _Atomic "desugaring" is not fully correct as it does more
than remove sugar, but it is the right thing to do for most of the
things that we care about. We can change this back once we decide to
support atomic types more comprehensively.
Reviewers: teemperor, shafik
Subscribers: jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71262
Summary:
This adds support for DWARF5 location lists which are specified
indirectly, via an index into the debug_loclists offset table. This
includes parsing the DW_AT_loclists_base attribute which determines the
location of this offset table, and support for new form DW_FORM_loclistx
which is used in conjuction with DW_AT_location to refer to the location
lists in this way.
The code uses the llvm class to parse the offset information, and I've
also tried to structure it similarly to how the relevant llvm
functionality works.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71268
When running the test suite with always capture on, a handful of tests
are failing because they have multiple targets and therefore multiple
GDB remote connections. The current reproducer infrastructure is capable
of dealing with that.
This patch reworks the GDB remote provider to support multiple GDB
remote connections, similar to how the reproducers support shadowing
multiple command interpreter inputs. The provider now keeps a list of
packet recorders which deal with a single GDB remote connection. During
replay we rely on the order of creation to match the number of packets
to the GDB remote connection.
Differential revision: https://reviews.llvm.org/D71105
Summary:
This patch deletes the lldb location list parser and teaches the
DWARFExpression class to use the parser in llvm instead. I have
centralized all the places doing the parsing into a single
GetLocationExpression function.
In theory the the actual location list parsing should be covered by llvm
tests, and this glue code by our existing location list tests, but since
we don't have that many location list tests, I've tried to extend the
coverage a bit by adding some explicit dwarf5 loclist handling and a
test of the dumping code.
For DWARF4 location lists this should be NFC (modulo small differences
in error handling which should only show up on invalid inputs). In case
of DWARF5, this fixes various missing bits of functionality, most
notably, the lack of support for DW_LLE_offset_pair.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: lldb-commits, dblaikie
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71003
Summary:
Lldb support base address selection entries in location lists was broken
for a long time. This wasn't noticed until llvm started producing these
kinds of entries more frequently with r374600.
In r374769, I made a quick patch which added sufficient support for them
to get the test suite to pass. However, I did not fully understand how
this code operates, and so the fix was not complete. Specifically, what
was lacking was the ability to handle modules which were not loaded at
their preferred load address (for instance, due to ASLR).
Now that I better understand how this code works, I've come to the
conclusion that the current setup does not provide enough information
to correctly process these entries. In the current setup the location
lists were parameterized by two addresses:
- the distance of the function start from the start of the compile unit.
The purpose of this was to make the location ranges relative to the
start of the function.
- the actual address where the function was loaded at. With this the
function-start-relative ranges can be translated to actual memory
locations.
The reason for the two values, instead of just one (the load bias) is (I
think) MachO, where the debug info in the object files will appear to be
relative to the address zero, but the actual code it refers to
can be moved and reordered by the linker. This means that the location
lists need to be "linked" to reflect the locations in the actual linked
file.
These two bits of information were enough to correctly process location
lists which do not contain base address selection entries (and so all
entries are relative to the CU base). However, they don't work with
them because, in theory two base address can be completely unrelated (as
can happen for instace with hot/cold function splitting, where the
linker can reorder the two pars arbitrarily).
To fix that, I split the first parameter into two:
- the compile unit base address
- the function start address, as is known in the object file
The new algorithm becomes:
- the location lists are processed as they were meant to be processed.
The CU base address is used as the initial base address value. Base
address selection entries can set a new base.
- the difference between the "file" and "load" function start addresses
is used to compute the load bias. This value is added to the final
ranges to get the actual memory location.
This algorithm is correct for non-MachO debug info, as there the
location lists correctly describe the code in the final executable, and
the dynamic linker can just move the entire module, not pieces of it. It
will also be correct for MachO if the static linker preserves relative
positions of the various parts of the location lists -- I don't know
whether it actually does that, but judging by the lack of base address
selection support in dsymutil and lldb, this isn't something that has
come up in the past.
I add a test case which simulates the ASLR scenario and demonstrates
that base address selection entries now work correctly here.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: dblaikie, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70532
Summary:
This patch adds support for atomic types (DW_TAG_atomic_type) to LLDB. It's mostly just filling out all the switch-statements that didn't implement Atomic case with the usual boilerplate.
Thanks Pavel for writing the test case.
Reviewers: labath, aprantl, shafik
Reviewed By: labath
Subscribers: jfb, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71183
In DWARF5 DW_AT_low_pc (and DW_AT_entry_pc, and possibly others) can use
DW_FORM_addrx to refer to the address indirectly. This means we need to
have processed the DW_AT_addr_base attribute before we can do anything
with these.
Since we were processing the unit attributes serially, this created a
problem in cases where the DW_AT_addr_base comes after DW_AT_low_pc --
we would end up computing the wrong unit base address, which also
corrupted any values which later depended on that (for instance range
lists). Clang currently always emits DW_AT_addr_base last.
The fix is simple -- process DW_AT_addr_base first, regardless of its
position in the attribute list.
the value of DW_AT_rnglists_base of the skeleton unit is for that unit
alone (e.g. used in DW_AT_ranges of the unit DIE) and should not apply
to the split unit.
The split unit has a hardcoded range list base value -- we should
initialize range list code whenever we detect a nonempty
debug_rnglists.dwo section.
Summary:
Our rnglist support was working only for the trivial cases (one CU),
because we only ever parsed one contribution out of the debug_rnglists
section. This means we were never able to resolve range lists for the
second and subsequent units (DW_FORM_sec_offset references came out
blang, and DW_FORM_rnglistx references always used the ranges lists from
the first unit).
Since both llvm and lldb rnglist parsers are sufficiently
self-contained, and operate similarly, we can fix this problem by
switching to the llvm parser instead. Besides the changes which are due
to variations in the interface, the main thing is that now the range
list object is a member of the DWARFUnit, instead of the entire symbol
file. This ensures that each unit can get it's own private set of range
list indices, and is consistent with how llvm's DWARFUnit does it
(overall, I've tried to structure the code the same way as the llvm
version).
I've also added a test case for the two unit scenario.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: dblaikie, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71021
Summary:
Lldb's "format-independent" debug info made use of the fact that DWARF
(<=4) did not use the file index zero, and reused the support file index
zero for storing the compile unit name.
While this provided some convenience for DWARF<=4, it meant that the PDB
plugin needed to artificially remap file indices in order to free up
index 0. Furthermore, DWARF v5 make file index 0 legal, which meant that
similar remapping would be needed in the dwarf plugin too.
What this patch does instead is remove the requirement of having the
compile unit name in the index 0. It is not that useful since the name
can always be fetched from the CompileUnit object. Remapping code in the
pdb plugin(s) has been removed or simplified.
DWARF plugin has started inserting an empty FileSpec at index 0 to
ensure the indices keep matching up (in case of DWARF<=4). For DWARF5,
we insert the file 0 from the line table.
I add a test to ensure we can correctly lookup line table entries
referencing file 0, and in particular the case where the file 0 is also
duplicated in another file entry, as this is how clang produces line
tables in some circumstances (see pr44170). Though this is probably a
bug in clang, this is not forbidden by DWARF, and lldb already has
support for that in some (but not all) cases -- this adds a test for the
code path which was not fixed in this patch.
Reviewers: clayborg, JDevlieghere, jdoerfert
Subscribers: aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70954
Make it possible to override reproducer capture with the
LLDB_CAPTURE_REPRODUCER environment variable.
The goal of this change is twofold.
(1) I want to be able to enable capturing reproducers during regular
test runs, both locally and on the bots. To do so I need a way to
force capture. I cannot do this through the Python API, because
reproducer capture must be enabled *before* the debugger
initialized, which happens automatically when doing `import lldb`.
(2) I want to provide an escape hatch for when reproducers are enabled
by default. Downstream we have reproducer capture enabled by default
in the driver.
This patch solves both problems by overriding the reproducer mode based
on the environment variable. Acceptable values are 0/1 and ON/OFF.
The previous fix attempt, in 62a635e864, used too much escaping
for the backslashes.
But instead of using regexes to match both path separator forms,
remove the path altogether to unify the output from the testcase
between platforms.
To ensure a reproducer works correctly, the version of LLDB used for
capture and replay must match. Right now the reproducer already contains
the LLDB version. However, this is purely informative. LLDB will happily
replay a reproducer generated with a different version of LLDB, which
can cause subtle differences.
This patch adds a version check which compares the current LLDB version
with the one in the reproducer. If the version doesn't match, LLDB will
refuse to replay. It also adds an escape hatch to make it possible to
still replay the reproducer without having to mess with the recorded
version. This might prove useful when you know two versions of LLDB
match, even though the version string doesn't. This behavior is
triggered by passing a new flag -reproducer-skip-version-check to the
lldb driver.
Differential revision: https://reviews.llvm.org/D70934
If filling in a DataExtractor from an ObjectFile, e.g. via the
ReadSectionData method, the output DataExtractor gets the address
size from the m_data member.
ObjectFile's m_data member is initialized without knowledge about
the address size (so the address size is set based on the host's
sizeof(void*), and at that point within ObjectFile's constructor,
virtual methods implemented in subclasses (like GetAddressByteSize())
can't be called, therefore fix it up when filling in external
DataExtractors.
This makes sure that line tables from executables with a different
address size are parsed properly; previously this tripped up
DWARFDebugLine::LineTable::parse for 32 bit executables on a 64 bit
host, as the address size in the line table (4) didn't match the
one set in the DWARFDataExtractor.
Differential Revision: https://reviews.llvm.org/D70848
Extend EmulateMOVRdRm to identify "mov r11, sp" in thumb mode as
setting the frame pointer, if r11 is the frame pointer register.
Differential Revision: https://reviews.llvm.org/D70797
Windows on ARM always uses thumb mode, and doesn't have most of the
mechanisms that are used in e.g. ELF for distinguishing between arm
and thumb.
Differential Revision: https://reviews.llvm.org/D70796
COFF section names can either be stored truncated to 8 chars, in the
section header, or as a longer section name, stored separately in the
string table.
libunwind locates the .eh_frame section by runtime introspection,
which only works for section names stored in the section header (as
the string table isn't mapped at runtime). To support this behaviour,
lld always truncates the section names for sections that will be
mapped, like .eh_frame.
Differential Revision: https://reviews.llvm.org/D70745
Summary:
I recently re-discovered that the unsinged stream operators of the
lldb_private::Stream class have a surprising behavior in that they print
the number in hex. This is all the more confusing because the "signed"
versions of those operators behave normally.
Now that, thanks to Raphael, each Stream class has a llvm::raw_ostream
wrapper, I think we should delete most of our formatting capabilities
and just delegate to that. This patch tests the water by just deleting
the operators with the most surprising behavior.
Most of the code using these operators was printing user_id_t values. It
wasn't fully consistent about prefixing them with "0x", but I've tried
to consistenly print it without that prefix, to make it more obviously
different from pointer values.
Reviewers: teemperor, JDevlieghere, jdoerfert
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70241
