This change makes sure that DwarfUnit does not load a .dwo file until
necessary. I also take advantage of DWARF 5's guarantee that the first
support file is also the primary file to make it possible to create
a compile unit without loading the .dwo file.
Testcases now require Linux as it is needed for -gsplit-dwarf.
Review By: jankratochvil, dblaikie
Differential Revision: https://reviews.llvm.org/D100299
This change makes sure that DwarfUnit does not load a .dwo file until
necessary. I also take advantage of DWARF 5's guarantee that the first
support file is also the primary file to make it possible to create
a compile unit without loading the .dwo file.
Review By: jankratochvil, dblaikie
Differential Revision: https://reviews.llvm.org/D100299
This change makes sure that DwarfUnit does not load a .dwo file until
necessary. I also take advantage of DWARF 5's guarantee that the first
support file is also the primary file to make it possible to create
a compile unit without loading the .dwo file.
Review By: jankratochvil, dblaikie
Differential Revision: https://reviews.llvm.org/D100299
when dealing with -gmodules debug info.
This fixes the bot failures on Darwin.
A recent clang change (presumably https://reviews.llvm.org/D104291)
introduced a bug where .pcm files would identify themselves as
DW_LANG_C_plus_plus, but the .o that references them would identify as
DW_LANG_C_plus_plus_14. While that bug needs to be fixed, too, it
shows that the current strict comparison also isn't meaningful.
rdar://79423225
This patch refactors a good part of the code base turning the usual
FileSpec, Line, Column, CheckInlines, ExactMatch arguments into a
SourceLocationSpec object.
This change is required for a following patch that will add handling of the
column line information when doing symbol resolution.
Differential Revision: https://reviews.llvm.org/D100965
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
I found a few cases where entries in the debug_line for a specific line of code have invalid entries (the address is outside of a code section or no section at all) and also valid entries. When this happens lldb might not set the breakpoint because the first line entry it will find in the line table might be the invalid one and since it's range is "invalid" no location is resolved. To get around this I changed the way we parse the line sequences to ignore those starting at an address under the first code segment.
Greg suggested to implement it this way so we don't need to check all sections for every line sequence.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D87172
Only SymbolFileDWARF::ParseCompileUnit creates a CompileUnit and it uses
DWARFCompileUnit for that.
Differential Revision: https://reviews.llvm.org/D89165
When debugging from a SymbolMap the creation of CompileUnits for the
individual object files is so lazy that RegisterXcodeSDK() is not
invoked at all before the Swift TypeSystem wants to read it. This
patch fixes this by introducing an explicit
SymbolFile::ParseXcodeSDK() call that can be invoked deterministically
before the result is required.
<rdar://problem/62532151+62326862>
https://reviews.llvm.org/D79273
Pavel Labath wrote in D73206:
The internal representation of DebugNames and Apple indexes is fixed by
the relevant (pseudo-)standards, so we can't really change it. The
question is how to efficiently (and cleanly) convert from the internal
representation to some common thing. The conversion from AppleIndex to
DIERef is trivial (which is not surprising as it was the first and the
overall design was optimized for that). With debug_names, the situation
gets more tricky. The internal representation of debug_names uses
CU-relative DIE offsets, but DIERef wants an absolute offset. That means
the index has to do more work to produce the common representation. And
it needs to do that for all results, even though a lot of the index
users are really interested only in a single entry. With the switch to
user_id_t, _all_ indexes would have to do some extra work to encode it,
only for their users to have to immediately decode it back. Having
a iterator/callback based api would allow us to minimize the impact of
that, as it would only need to happen for the entries that are really
used. And /I think/ we could make it interface returns DWARFDies
directly, and each index converts to that using the most direct approach
available.
Jan Kratochvil:
It also makes all the callers shorter as they no longer need to fetch
DWARFDIE from DIERef (and handling if not found by ReportInvalidDIERef)
but the callers are already served DWARFDIE which they need.
In some cases the DWARFDIE had to be fetched both by callee (DWARFIndex
implementation) and caller.
Differential Revision: https://reviews.llvm.org/D77970
Summary:
Currently `SymbolFileDWARF::TypeSet` is a typedef to a `std::set<Type *>`.
In `SymbolFileDWARF::GetTypes` we iterate over a TypeSet variable when finding
types so that logic is non-deterministic as it depends on the actual pointer address values.
This patch changes the `TypeSet` to a `llvm::UniqueVector` which always iterates in
the order in which we inserted the types into the list.
Reviewers: JDevlieghere, aprantl
Reviewed By: JDevlieghere
Subscribers: mgrang, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D75481
Summary:
When we added support for type units in dwo files, we changed the
"manual" dwarf index to index _all_ dwarf units in the dwo file instead
of just the split unit belonging to our skeleton unit. This was fine for
dwo files, as they contain only a single compile units and type units do
not have a split type unit which would point to them.
However, this does not work for dwp files because, these files do
contain multiple split compile units, and the current approach means
that each unit gets indexed multiple times (once for each split unit =>
n^2 complexity).
This patch teaches the manual dwarf index to treat dwp files specially.
Any type units in the dwp file added to the main list of compile units
and indexed with them in a single batch. Split compile units in dwp
files are still indexed as a part of their skeleton unit -- this is done
because we need the DW_AT_language attribute from the skeleton unit to
index them properly.
Handling of dwo files remains unchanged -- all units (type and skeleton)
are indexed when we reach the dwo file through the split unit.
Reviewers: clayborg, JDevlieghere, aprantl
Subscribers: arphaman, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74964
Change the return value of SymbolFileDWARF::DebugInfo from a pointer to
a reference, and remove all null checks.
Previously, we were not constructing the DebugInfo object when the
debug_info section was empty. Now we always construct the object but
it will return an empty list of dwarf units (a thing which it already
supported).
Summary:
All of our lookup APIs either use `CompilerDeclContext &` or `CompilerDeclContext *` semi-randomly it seems.
This leads to us constantly converting between those two types (and doing nullptr checks when going from
pointer to reference). It also leads to the confusing situation where we have two possible ways to express
that we don't have a CompilerDeclContex: either a nullptr or an invalid CompilerDeclContext (aka a default
constructed CompilerDeclContext).
This moves all APIs to use references and gets rid of all the nullptr checks and conversions.
Reviewers: labath, mib, shafik
Reviewed By: labath, shafik
Subscribers: shafik, arphaman, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74607
LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.
Differential revision: https://reviews.llvm.org/D74743
As discussed in https://reviews.llvm.org/D73206#1871895 there is both
`DIERef` and `user_id_t` and sometimes (for DWZ) we need to encode Main
CU into them and sometimes we cannot as it is unavailable at that point
and at the same time not even needed.
I have also noticed `DIERef` and `user_id_t` in fact contain the same
information which can be seen in SymbolFileDWARF::GetUID.
SB* API/ABI is already using `user_id_t` and it needs to encode Main CU
for DWZ. Therefore what about making `DIERef` the identifier not
containing Main CU and `user_id_t` the identifier containing Main CU?
It is sort of a revert of D63322.
I find this patch as a NFC cleanup to the codebase - to satisfy a new
premise `user_id_t` is used as little as possible and thus only for
external interfaces which must not deal with MainCU in any way.
Its larger goal is to satisfy a plan to implement DWZ support.
Differential Revision: https://reviews.llvm.org/D74637
Summary:
This patch removes the bitrotted SymbolFileDWARF(Dwo)Dwp classes, and
replaces them with dwp support implemented directly inside
SymbolFileDWARFDwo, in a manner mirroring the implementation in llvm.
This patch does:
- add support for the .debug_cu_index section to our DWARFContext
- adds a llvm::DWARFUnitIndex argument to the DWARFUnit constructors.
This argument is used to look up the offsets of the debug_info and
debug_abbrev contributions in the sections of the dwp file.
- makes sure the creation of the DebugInfo object as well as the initial
discovery of DWARFUnits is thread-safe, as we can now call this
concurrently when doing parallel indexing.
This patch does not:
- use the DWARFUnitIndex to search for other kinds of contributions
(debug_loc, debug_ranges, etc.). This means that units which reference
these sections will not work correctly. These will be handled by
follow-up patches, but even the present level of support is sufficient
to enable basic functionality.
- Make the llvm::DWARFContext thread-safe. Right now, it just avoids this
problem by ensuring everything is initialized ahead of time. However,
this is something we will run into more often as we try to use more of
llvm, and so I plan to start looking into our options here.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: mgorny, mgrang, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73783
This is the second dwp preparatory patch. When a SymbolFileDWARFDwo will
hold more than one split unit, it will not be able to be uniquely owned
by a single DWARFUnit. I achieve this by changing the
unique_ptr<SymbolFileDWARFDwo> member of DWARFUnit to
shared_ptr<DWARFUnit>. The shared_ptr points to a DWARFUnit, but it is
in fact holding the entire SymbolFileDWARFDwo alive. This is the same
method used by llvm DWARFUnit (except that is uses the DWARFContext
class).
Differential Revision: https://reviews.llvm.org/D73782
Summary:
This is a preparatory patch to re-enable DWP support in lldb (we already
have code claiming to do that, but it has been completely broken for a
while now).
The idea of the new approach is to make the SymbolFileDWARFDwo class
handle both dwo and dwo files, similar to how llvm uses one DWARFContext
to handle the two.
The first step is to remove the assumption that a SymbolFileDWARFDwo
holds just a single compile unit, i.e. the GetBaseCompileUnit method.
This requires changing the way how we reach the skeleton compile unit
(and the lldb_private::CompileUnit) from a dwo unit, which was
previously done via GetSymbolFile()->GetBaseCompileUnit() (and some
virtual dispatch).
The new approach reuses the "user data" mechanism of DWARFUnits, which
was used to link dwarf units (both skeleton and split) to their
lldb_private counterparts. Now, this is done only for non-dwo units, and
instead of that, the dwo units holds a pointer to the relevant skeleton
unit.
Reviewers: JDevlieghere, aprantl, clayborg
Reviewed By: JDevlieghere, clayborg
Subscribers: arphaman, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73781
Reverting part of commit 789beeeca3.
Its DWARFDebugInfoEntry::GetDWARFDeclContext() refactorization for
return value is now adding it in opposite order.
This patchset is removing non-DWARF code from DWARFUnit for better
future merge with LLVM DWARF as discussed with @labath.
Differential revision: https://reviews.llvm.org/D70646
- m_debug_loc(lists) are unused since the relevant logic was moved to
DWARFContext.
- const versions of DebugInfo(), DebugAbbrev() are not used, and they
are dangerous to use as they do not initialize the relevant objects.
Summary:
Our DWARFUnit was automatically forwarding the requests to the split
unit when looking for a DIE by offset. llvm::DWARFUnit does not do that,
and is not likely to start doing it any time soon.
This patch deletes the this logic and updates the callers to request the
correct unit instead. While doing that, I've found a bit of duplicated
code for lookup up a function and block by address, so I've extracted
that into a helper function.
Reviewers: JDevlieghere, aprantl, clayborg, jdoerfert
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73112
Summary:
This code is handling debug info paths starting with /proc/self/cwd,
which is one of the mechanisms people use to obtain "relocatable" debug
info (the idea being that one starts the debugger with an appropriate
cwd and things "just work").
Instead of resolving the symlinks inside DWARFUnit, we can do the same
thing more elegantly by hooking into the existing Module path remapping
code. Since llvm::DWARFUnit does not support any similar functionality,
doing things this way is also a step towards unifying llvm and lldb
dwarf parsers.
Reviewers: JDevlieghere, aprantl, clayborg, jdoerfert
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71770
This reverts D53469, which changed llvm's DWARF emission to emit
DW_AT_call_return_pc as a function-local offset. Such an encoding is not
compatible with post-link block re-ordering tools and isn't standards-
compliant.
In addition to reverting back to the original DW_AT_call_return_pc
encoding, teach lldb how to fix up DW_AT_call_return_pc when the address
comes from an object file pointed-to by a debug map. While doing this I
noticed that lldb's support for tail calls that cross a DSO/object file
boundary wasn't covered, so I added tests for that. This latter case
exercises the newly added return PC fixup.
The dsymutil changes in this patch were originally included in D49887:
the associated test should be sufficient to test DW_AT_call_return_pc
encoding purely on the llvm side.
Differential Revision: https://reviews.llvm.org/D72489
These are the last sections not managed by the DWARFContext object. I
also introduce separate SectionType enums for dwo section variants, as
this is necessary for proper handling of single-file split dwarf.
Summary:
Our code was expecting that a single (symbol) file contains only one
kind of location lists. This is not correct (on non-apple platforms, at
least) as a file can compile units with different dwarf versions.
This patch moves the deteremination of location list flavour down to the
compile unit level, fixing this problem. I have also tried to rougly
align the code with the llvm DWARFUnit. Fully matching the API is not
possible because of how lldb's DWARFExpression lives separately from the
rest of the DWARF code, but this is at least a step in the right
direction.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: dblaikie, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71751
Summary:
A skeleton unit can easily be detected by checking the m_dwo_symbol_file
member, but we cannot tell a split unit from a normal unit from the
"inside", which is sometimes useful.
This patch adds a m_is_dwo member to enable this, and align the code
with llvm::DWARFUnit. Right now it's only used to avoid creating a split
unit inside another split unit (which removes one override from
SymbolFileDWARFDwo and brings us a step closer to deleting it), but my
main motivation is fixing the handling of location lists in mixed v4&v5
files. This comes in a separate patch.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: dblaikie, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71750
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
Split CallEdge into DirectCallEdge and IndirectCallEdge. Teach
DWARFExpression how to evaluate entry values in cases where the current
activation was created by an indirect call.
rdar://57094085
Differential Revision: https://reviews.llvm.org/D70100
This feature is mostly there to aid debugging of Clang module issues,
since the only useful actual the end-user can to is to recompile their
program.
Differential Revision: https://reviews.llvm.org/D70272
I wanted to further simplify ParseTypeFromClangModule by replacing the
hand-rolled loop with ForEachExternalModule, and then realized that
ForEachExternalModule also had the problem of visiting the same leaf
node an exponential number of times in the worst-case. This adds a set
of searched_symbol_files set to the function as well as the ability to
early-exit from it.
Differential Revision: https://reviews.llvm.org/D70215
This avoids confusing them with fission-related functionality.
I also moved two accessor functions from DWARFDIE into static
functions in DWARFASTParserClang were their only use is located.
This is basically the same bug as in r260434.
SymbolFileDWARF::FindTypes has exponential worst-case when digging
through dependency DAG of .pcm files because each object file and .pcm
file may depend on an already-visited .pcm file, which may again have
dependencies. Fixed here by carrying a set of already visited
SymbolFiles around.
rdar://problem/56993424
Differential Revision: https://reviews.llvm.org/D70106
This patch removes the size_t return value and the append parameter
from the remainder of the Find.* functions in LLDB's internal API. As
in the previous patches, this is motivated by the fact that these
parameters aren't really used, and in the case of the append parameter
were frequently implemented incorrectly.
Differential Revision: https://reviews.llvm.org/D69119
llvm-svn: 375160
In r368345 I accidentally introduced a regression that would
over-report the number of matches found by FindTypes if the
DeclContext Filter was hit.
This patch simply removes the size_t return parameter altogether —
it's not that useful.
rdar://problem/55500457
Differential Revision: https://reviews.llvm.org/D68169
llvm-svn: 373344
I noticed that SymbolFileDWARFDebugMap::FindTypes was implementing it
incorrectly (passing append=false in a for-loop to recursive calls to
FindTypes would yield only the very last set of results), but instead
of fixing it, removing it seemed like an even better option.
rdar://problem/54412692
Differential Revision: https://reviews.llvm.org/D68171
llvm-svn: 373224
Summary:
At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program
and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to
cause a few problems or inconveniences:
* It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible
for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default
(and we can't just close all the associated bug reports).
* Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux).
* We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS).
This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit.
If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module
configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information
than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the
`Darwin` module are their own external type module with their own files).
The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths
based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some
test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism),
but for now it works and makes the feature usable.
Reviewers: aprantl, shafik, jdoerfert
Reviewed By: aprantl
Subscribers: mgorny, abidh, JDevlieghere, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D67760
llvm-svn: 372716
This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.
In multi-language projects it is extremely common to have, e.g., a
Clang type and a similarly-named rendition of that same type in
another language. When searching for a type It is much cheaper to pass
a set of supported languages to the SymbolFile than having it
materialize every result and then rejecting the materialized types
that have the wrong language.
Differential Revision: https://reviews.llvm.org/D66546
<rdar://problem/54471165>
This reapplies r369690 with a previously missing constructor for LanguageSet.
llvm-svn: 369710
This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.
In multi-language projects it is extremely common to have, e.g., a
Clang type and a similarly-named rendition of that same type in
another language. When searching for a type It is much cheaper to pass
a set of supported languages to the SymbolFile than having it
materialize every result and then rejecting the materialized types
that have the wrong language.
Differential Revision: https://reviews.llvm.org/D66546
<rdar://problem/54471165>
llvm-svn: 369690
