When the debug info refers to a dwo with relative `DW_AT_comp_dir` and
`DW_AT_dwo_name`, we only print the `DW_AT_comp_dir` in our error
message if we can't find it. This often isn't very helpful, especially
when the `DW_AT_comp_dir` is ".":
```
(lldb) fr v
error: unable to locate .dwo debug file "." for skeleton DIE 0x000000000000003c
```
I'm updating the error message to include both `DW_AT_comp_dir` (if it
exists) and `DW_AT_dwo_name` when the `DW_AT_dwo_name` is relative. The
behavior when `DW_AT_dwo_name` is absolute should be the same.
In an upcoming patch, D142556, Clang is proposed to be changed to emit
line locations that are inlined at line 0. This clashed with the behavior of
GetDIENamesAndRanges() which used 0 as a default value to determine if
file, line or column numbers had been set. Users of that function then
checked for any non-0 values when setting up the call site:
if (call_file != 0 || call_line != 0 || call_column != 0)
[...]
which did not work with the Clang change since all three values then
could be 0.
This changes the function to use std::optional to catch non-set values
instead.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D142552
This fixes a regression introduced by
https://reviews.llvm.org/D131437. The intention of the patch was to
avoid indexing DWO skeleton units, but it also skipped over full DWARF
compile units linked via a -gmodules DW_AT_dwo_name attribute. This
patch restores the functionality and adds a test for it.
Differential Revision: https://reviews.llvm.org/D142683
By moving them into a folder with a local lit config
requiring x86. All these tests use x86 target triples.
There are two tests that require target-x86_64 because
they run program files (instead of just needing the backend).
Those are moved to the x86 folder also but their REQUIRES are
unchanged.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D100193
Apply changes from https://reviews.llvm.org/D91014 to other places where DWARF entries are being processed.
Test case is provided by @jankratochvil.
The test is marked to run only on x64 and exclude Windows and Darwin, because the assembly is not OS-independent.
(First attempt https://reviews.llvm.org/D96778 broke the build bots)
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D97765
Finishing out the support (to the best of my knowledge/based on current
testing running the whole check-lldb with a clang forcibly using
DW_AT_ranges on all DW_TAG_subprograms) for this feature.
Differential Revision: https://reviews.llvm.org/D94064
gcc already produces debug info with this form
-freorder-block-and-partition
clang produces this sort of thing with -fbasic-block-sections and with a
coming-soon tweak to use ranges in DWARFv5 where they can allow greater
reuse of debug_addr than the low/high_pc forms.
This fixes the case of breaking on a function name, but leaves broken
printing a variable - a follow-up commit will add that and improve the
test case to match.
Differential Revision: https://reviews.llvm.org/D94063
GNU ld allows sections after a non-SHF_ALLOC section to be covered by PT_LOAD
(PR37607) and assigns addresses to non-SHF_ALLOC output sections (similar to
SHF_ALLOC NOBITS sections. The location counter is not advanced).
This patch tries to fix PR37607 (remove a special case in
`Writer<ELFT>::createPhdrs`). To make the created PT_LOAD meaningful, we cannot
reset dot to 0 for a middle non-SHF_ALLOC output section. This results in
removal of two special cases in LinkerScript::assignOffsets. Non-SHF_ALLOC
non-orphan sections can have non-zero addresses like in GNU ld.
The zero address rule for non-SHF_ALLOC sections is weakened to apply to orphan
only. This results in a special case in createSection and findOrphanPos, respectively.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D85100
The relevant output FileCheck is scanning in this test is as follows:
CXXRecordDecl 0x7f96cf8239c8 <<invalid sloc>> <invalid sloc> imported in A.B <undeserialized declarations> struct definition
<<DefinitionData boilerplate>>
`-FieldDecl 0x7f96cf823b90 <<invalid sloc>> <invalid sloc> imported in A.B anon_field_b 'int'
(anonymous struct)
CXXRecordDecl 0x7f96cf823be8 <<invalid sloc>> <invalid sloc> imported in A.B struct
Before 710fa2c4ee346e1ec2db66ac5fdf6909e79d9a8c this test was passing by
accident as it had a -DAG suffix in the checks changed by this patch,
causing FileCheck to first match the last line of the output above
(instead of the first one), and then finding the FieldDecl above.
When I removed the -DAG suffix, FileCheck actually enforced the ordering
and started failing as the FieldDecl comes before the CXXRecordDecl match
we get.
This patch fixes the CXXRecordDecl check to find the first line of the output
above which caused FileCheck to also find the FieldDecl that follows. Also
gives the FieldDecl a more unique name to make name collisions less likely.
This patch threads an lldb::DescriptionLevel through the typesystem to
allow dumping the full Clang AST (level=verbose) of any lldb::Type in
addition to the human-readable source description (default
level=full). This type dumping interface is currently not exposed
through the SBAPI.
The application is to let lldb-test dump the clang AST of search
results. I need this to test lazy type completion of clang types in
subsequent patches.
Differential Revision: https://reviews.llvm.org/D78329
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
1;95;0csets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.
This reapplies the previously reverted commit, but without support for
ClassTemplateSpecializations, which I'm going to look into separately.
rdar://problem/59634380
Differential Revision: https://reviews.llvm.org/D75488
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
sets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.
rdar://problem/59634380
Differential Revision: https://reviews.llvm.org/D75488
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
LLDB has three major testing strategies: unit tests, tests that exercise
the SB API though dotest.py and what we currently call lit tests. The
later is rather confusing as we're now using lit as the driver for all
three types of tests. As most of this grew organically, the directory
structure in the LLDB repository doesn't really make this clear.
The 'lit' tests are part of the root and among these tests there's a
Unit and Suite folder for the unit and dotest-tests. This layout makes
it impossible to run just the lit tests.
This patch changes the directory layout to match the 3 testing
strategies, each with their own directory and their own configuration
file. This means there are now 3 directories under lit with 3
corresponding targets:
- API (check-lldb-api): Test exercising the SB API.
- Shell (check-lldb-shell): Test exercising command line utilities.
- Unit (check-lldb-unit): Unit tests.
Finally, there's still the `check-lldb` target that runs all three test
suites.
Finally, this also renames the lit folder to `test` to match the LLVM
repository layout.
Differential revision: https://reviews.llvm.org/D68606
llvm-svn: 374184
