DWP files don't usually have a GNU build ID built into them. When
searching for a .dwp file, don't require a UUID to be in the .dwp file.
The debug info search information was checking for a UUID in the .dwp
file when debug info search paths were being used. This is now fixed by
not specifying the UUID in the ModuleSpec being used for the .dwp file
search.
When using split DWARF we can run into many different ways to store
debug info:
- lldb loads `<exe>` which contains skeleton DWARF and needs to find
`<exe>.dwp`
- lldb loads `<exe>` which is stripped but has .gnu_debuglink pointing
to `<exe>.debug` with skeleton DWARF and needs to find `<exe>.dwp`
- lldb loads `<exe>` which is stripped but has .gnu_debuglink pointing
to `<exe>.debug` with skeleton DWARF and needs to find `<exe>.debug.dwp`
- lldb loads `<exe>.debug` and needs to find `<exe>.dwp`
Previously we only handled the first two cases. This patch adds support
for the latter two.
When using split DWARF with .dwp files we had an issue where sometimes
the DWO file within the .dwp file would be parsed _before_ the skeleton
compile unit. The DWO file expects to be able to always be able to get a
link back to the skeleton compile unit. Prior to this fix, the only time
the skeleton compile unit backlink would get set, was if the unit
headers for the main executable have been parsed _and_ if the unit DIE
was parsed in that DWARFUnit. This patch ensures that we can always get
the skeleton compile unit for a DWO file by adding a function:
```
DWARFCompileUnit *DWARFUnit::GetSkeletonUnit();
```
Prior to this fix DWARFUnit had some unsafe accessors that were used to
store two different things:
```
void *DWARFUnit::GetUserData() const;
void DWARFUnit::SetUserData(void *d);
```
This was used by SymbolFileDWARF to cache the `lldb_private::CompileUnit
*` for a SymbolFileDWARF and was also used to store the `DWARFUnit *`
for SymbolFileDWARFDwo. This patch clears up this unsafe usage by adding
two separate accessors and ivars for this:
```
lldb_private::CompileUnit *DWARFUnit::GetLLDBCompUnit() const { return m_lldb_cu; }
void DWARFUnit::SetLLDBCompUnit(lldb_private::CompileUnit *cu) { m_lldb_cu = cu; }
DWARFCompileUnit *DWARFUnit::GetSkeletonUnit();
void DWARFUnit::SetSkeletonUnit(DWARFUnit *skeleton_unit);
```
This will stop anyone from calling `void *DWARFUnit::GetUserData()
const;` and casting the value to an incorrect value.
A crash could occur in `SymbolFileDWARF::GetCompUnitForDWARFCompUnit()`
when the `non_dwo_cu`, which is a backlink to the skeleton compile unit,
was not set and was NULL. There is an assert() in the code, and then the
code just will kill the program if the assert isn't enabled because the
code looked like:
```
if (dwarf_cu.IsDWOUnit()) {
DWARFCompileUnit *non_dwo_cu =
static_cast<DWARFCompileUnit *>(dwarf_cu.GetUserData());
assert(non_dwo_cu);
return non_dwo_cu->GetSymbolFileDWARF().GetCompUnitForDWARFCompUnit(
*non_dwo_cu);
}
```
This is now fixed by calling the `DWARFUnit::GetSkeletonUnit()` which
will correctly always get the skeleton compile uint for a DWO file
regardless of if the skeleton unit headers have been parse or if the
skeleton unit DIE wasn't parsed yet.
To implement the ability to get the skeleton compile units, I added code
the DWARFDebugInfo.cpp/.h that make a map of DWO ID -> skeleton
DWARFUnit * that gets filled in for DWARF5 when the unit headers are
parsed. The `DWARFUnit::GetSkeletonUnit()` will end up parsing the unit
headers of the main executable to fill in this map if it already hasn't
been done. For DWARF4 and earlier we maintain a separate map that gets
filled in only for any DWARF4 compile units that have a DW_AT_dwo_id or
DW_AT_gnu_dwo_id attributes. This is more expensive, so this is done
lazily and in a thread safe manor. This allows us to be as efficient as
possible when using DWARF5 and also be backward compatible with DWARF4 +
split DWARF.
There was also an issue that stopped type lookups from succeeding in
`DWARFDIE SymbolFileDWARF::GetDIE(const DIERef &die_ref)` where it
directly was accessing the `m_dwp_symfile` ivar without calling the
accessor function that could end up needing to locate and load the .dwp
file. This was fixed by calling the
`SymbolFileDWARF::GetDwpSymbolFile()` accessor to ensure we always get a
valid value back if we can find the .dwp file. Prior to this fix it was
down which APIs were called and if any APIs were called that loaded the
.dwp file, it worked fine, but it might not if no APIs were called that
did cause it to get loaded.
When we have valid debug info indexes and when the lldb index cache was
enabled, this would cause this issue to show up more often.
I modified an existing test case to test that all of this works
correctly and doesn't crash.
…ntext
Following the specification chain seems to be clearly the expected
behavior of GetDeclContext(). Otherwise C++ methods have an empty
CompilerContext instead of being nested in their struct/class.
Theprimary motivation for this functionality is the Swift plugin. In
order to test the change I added a proof-of-concept implementation of a
Module::FindFunction() variant that takes a CompilerContext, expesed via
lldb-test.
rdar://120553412
This is a follow up patch after .debug_names can now emit local type
unit entries when we compile with type units + DWARF5 + .debug_names.
The pull request that added this functionality was:
https://github.com/llvm/llvm-project/pull/70515
This patch makes sure that the DebugNamesDWARFIndex in LLDB will not
manually need to parse type units if they have a valid index. It also
fixes the index to be able to correctly extract name entries that
reference type unit DIEs. Added a test to verify things work as
expected.
This patch resolves an issue that currently accounts for the vast
majority of failures on the matrix bot.
Differential Revision: https://reviews.llvm.org/D152872
This patch resolves an issue where a value
is incorrectly displayed if it is represented
by DW_OP_div.
This issue is caused by lldb evaluating
operands of DW_OP_div as unsigned
and performed unintended unsigned
division.
This issue is resolved by creating two
temporary signed scalar and performing
signed division.
(Addresses GH#61727)
Differential Revision: https://reviews.llvm.org/D147370
This patch resolves an issue where a value
is incorrectly displayed if it is represented
by DW_OP_div.
This issue is caused by lldb evaluating
operands of DW_OP_div as unsigned
and performed unintended unsigned
division.
This issue is resolved by creating two
temporary signed scalar and performing
signed division.
(Addresses GH#61727)
Differential Revision: https://reviews.llvm.org/D147370
This test previously relied on just segfaulting or not. This commit adds
a CHECK statement to the test.
Differential Revision: https://reviews.llvm.org/D148151
The function DWARFASTParserClang::ParsePointerToMemberType attempts to make
two pointers and then immediately tries to dereference them, without
verifying that the pointesr were successfully created. Sometimes the pointer
creation fails, and the dereference then causes a segfault. This add a check
that the pointers are non-null before attempting to dereference them.
In Shell tests, replace use of the `p` alias with the `expression` command.
To avoid conflating tests of the alias with tests of the expression command,
this patch canonicalizes to the use `expression`.
See also D141539 which made the same change to API tests.
Differential Revision: https://reviews.llvm.org/D146230
This came out of from https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902
With big binaries we can have .dwp files where .debug_info.dwo section can grow
beyond 4GB. We would like to support this in LLVM and in LLDB.
The plan is to enable manual parsing of cu/tu index in DWARF library
(https://reviews.llvm.org/D137882), and then
switch internal index data structure to 64 bit.
For the second part is to enable 64bit offset support in LLDB with
this patch.
Depends on D139955
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D138618
lldb may crash when performing `image lookup --verbose --address $ADDR`.
The ExecutionContext that gets passed into DWARFExpression::Evaluate may
be valid but unpopulated. However, in one specific case, we were
assuming that it has a valid Target and using it without checking first.
We reach this codepath when we attempt to get information about an
address that doesn't map to a CompileUnit in the module containing the
requested address. lldb then checks to see if it maps to a global
variable, so lldb has to evaluate the location of each global variable
in the module. If a location expression contains DW_OP_deref_size that
uses a FileAddress, we hit this code path. The simplest test case is to
take a module that has a global variable with DW_OP_deref_size in its
location expression, attempt to read an address that doesn't map to a
CompileUnit (e.g. 0x0) and ensure we don't crash.
Differential Revision: https://reviews.llvm.org/D143792
In preparation for eanbling 64bit support in LLDB switching to use llvm::formatv
instead of format MACROs.
Reviewed By: labath, JDevlieghere
Differential Revision: https://reviews.llvm.org/D139955
clang 14 removed -gz=zlib-gnu support and ld.lld/llvm-objcopy removed zlib-gnu
support recently. Remove lldb support by migrating away from
llvm::object::Decompressor::isCompressedELFSection.
The API has another user llvm-dwp, so it is not removed in this patch.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D129724
Because the diagnostic events are processed by the default event handler
in its own thread, tests cannot rely on output ordering. Split stdout
and stderr to make the test reliable again.
plugin to get queried earlier on in the startup, so that for .s files
we call the language "unknown" not "not-loaded". This test was checking
against that string, so I fixed it for the change.
See [[ https://github.com/llvm/llvm-project/issues/55040 | issue 55040 ]] where static members of classes declared in the anonymous namespace are incorrectly returned as member fields from lldb::SBType::GetFieldAtIndex(). It appears that attrs.member_byte_offset contains a sentinel value for members that don't have a DW_AT_data_member_location.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D124409
Added implementation to support DWARF5 in monolithic mode.
Next step DWARF5 split dwarf support.
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D121876
Currently DW_OP_deref_size just drops the ValueType::FileAddress case and does
not attempt to handle it. This adds support for this case and a test that
verifies this support.
I did a little refactoring since DW_OP_deref and DW_OP_deref_size have some
overlap in code.
Also see: rdar://66870821
Differential Revision: https://reviews.llvm.org/D121408
Embedded nul characters are still printed, and they don't terminate the
string. See also D111634.
Differential Revision: https://reviews.llvm.org/D120803
This ensures that the user is aware that many commands will not work
correctly.
We print the warning only once (per module) to avoid spamming the user
with potentially thousands of error messages.
Differential Revision: https://reviews.llvm.org/D120892
This allows `image lookup -a ... -v` to print variables only if the given
address is covered by the valid ranges of the variables. Since variables created
in dwarf plugin always has empty scope range, print the variable if it has
empty scope.
Differential Revision: https://reviews.llvm.org/D119963
In the rush to get the bot green, I did not realize I was building the
file with -gsplit-dwarf, and therefore the yaml ended up referring to a
file I did not check it.
This rebuilds the file without split dwarf.
In D117744, llvm removed writing support for this format, breaking the
test. We may eventually want to remove reading support as well, but for
now I have converted the test to a yaml file to maintain coverage.
LLDB build were failing due to following two test failures:
lldb-shell :: ObjectFile/ELF/basic-info.yaml
lldb-shell :: SymbolFile/DWARF/x86/debug-types-address-ranges.s
There were caused by commit 6506907a0a
Front-load the first_valid_code_address check, so that we avoid creating
the function object (instead of simply refusing to use it in queries).
Differential Revision: https://reviews.llvm.org/D112310
Based on post-commit review discussion on
2bd8493847 with Richard Smith.
Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).
This was originally committed in 277623f4d5
Reverted in f9ad1d1c77 due to breakages
outside of clang - lldb seems to have some strange/strong dependence on
"char [N]" versus "char[N]" when printing strings (not due to that name
appearing in DWARF, but probably due to using clang to stringify type
names) that'll need to be addressed, plus a few other odds and ends in
other subprojects (clang-tools-extra, compiler-rt, etc).
This patch fixes a problem introduced by clang change
https://reviews.llvm.org/D95617 and described by
https://bugs.llvm.org/show_bug.cgi?id=50076#c6, where inlined functions
omit unused parameters both in the stack trace and in `frame var`
command. With this patch, the parameters are listed correctly in the
stack trace and in `frame var` command.
Specifically, we parse formal parameters from the abstract version of
inlined functions and use those formal parameters if they are missing
from the concrete version.
Differential Revision: https://reviews.llvm.org/D110571
specifically, ignore addresses that point before the first code section.
This resurrects D87172 with several notable changes:
- it fixes a bug where the early exits in InitializeObject left
m_first_code_address "initialized" to LLDB_INVALID_ADDRESS (0xfff..f),
which caused _everything_ to be ignored.
- it extends the line table fix to function parsing as well, where it
replaces a similar check which was checking the executable permissions
of the section. This was insufficient because some
position-independent elf executables can have an executable segment
mapped at file address zero. (What makes this fix different is that it
checks for the executable-ness of the sections contained within that
segment, and those will not be at address zero.)
- It uses a different test case, with an elf file with near-zero
addresses, and checks for both line table and function parsing.
Differential Revision: https://reviews.llvm.org/D112058
When we know the bounds of the array, print any embedded nuls instead of
treating them as terminators. An exception to this rule is made for the
nul character at the very end of the string. We don't print that, as
otherwise 99% of the strings would end in \0. This way the strings
usually come out the same as how the user typed it into the compiler
(char foo[] = "with\0nuls"). It also matches how they come out in gdb.
This resolves a FIXME left from D111399, and leaves another FIXME for dealing
with nul characters in "escape-non-printables=false" mode. In this mode the
characters cause the entire summary string to be terminated prematurely.
Differential Revision: https://reviews.llvm.org/D111634
This reverts c7f16ab3e3 / r109694 - which
suggested this was done to improve consistency with the gdb test suite.
Possible that at the time GCC did not canonicalize integer types, and so
matching types was important for cross-compiler validity, or that it was
only a case of over-constrained test cases that printed out/tested the
exact names of integer types.
In any case neither issue seems to exist today based on my limited
testing - both gdb and lldb canonicalize integer types (in a way that
happens to match Clang's preferred naming, incidentally) and so never
print the original text name produced in the DWARF by GCC or Clang.
This canonicalization appears to be in `integer_types_same_name_p` for
GDB and in `TypeSystemClang::GetBasicTypeEnumeration` for lldb.
(I tested this with one translation unit defining 3 variables - `long`,
`long (*)()`, and `int (*)()`, and another translation unit that had
main, and a function that took `long (*)()` as a parameter - then
compiled them with mismatched compilers (either GCC+Clang, or
Clang+(Clang with this patch applied)) and no matter the combination,
despite the debug info for one CU naming the type "long int" and the
other naming it "long", both debuggers printed out the name as "long"
and were able to correctly perform overload resolution and pass the
`long int (*)()` variable to the `long (*)()` function parameter)
Did find one hiccup, identified by the lldb test suite - that CodeView
was relying on these names to map them to builtin types in that format.
So added some handling for that in LLVM. (these could be split out into
separate patches, but seems small enough to not warrant it - will do
that if there ends up needing any reverti/revisiting)
Differential Revision: https://reviews.llvm.org/D110455
This patch considers the CU index entry
when reading the .debug_rnglists.dwo section.
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D107456
Skeleton vs. DWO units mismatch has been fixed in D106270. As they both
have type DWARFUnit it is a bit difficult to debug. So it is better to
make it safe against future changes.
Reviewed By: kimanh, clayborg
Differential Revision: https://reviews.llvm.org/D107659
When going through the CU entries in the name index,
make sure to compare the name entry's CU
offset against the skeleton CU's offset.
Previously there would be a mismatch, since the
wrong offset was compared, and thus no suitable
entry was found.
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D106270
Summary:
In the spirit of https://reviews.llvm.org/D70846, we only return functions with
matching mangled name from Apple/DebugNamesDWARFIndex::GetFunction if
eFunctionNameTypeFull is requested.
This speeds up lookup in the presence of large amount of class methods of the
same name (a typical examples would be constructors of templates with many
instantiations or overloaded operators).
Reviewers: labath, teemperor
Reviewed By: labath, teemperor
Subscribers: aprantl, arphaman, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73191
This patch fixes the lookup of locations in
.debug_loclists, if they are split in a .dwp file.
Mainly, we need to consider the cu index offsets.
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D107161
