Make DWARFUnit use the dwo_id from the DWARF5 CU header.

In split DWARF v5 files, the DWO id is no longer in the DW_AT_GNU_dwo_id
attribute. It's in the CU header instead. This change makes lldb loo

Make DWARFUnit use the dwo_id from the DWARF5 CU header.

In split DWARF v5 files, the DWO id is no longer in the DW_AT_GNU_dwo_id
attribute. It's in the CU header instead. This change makes lldb look in
both places.

Differential Revision: https://reviews.llvm.org/D93444

show more ...

[nfc] [lldb] DWARF callbacks: DIERef -> DWARFDIE

Pavel Labath wrote in D73206:
The internal representation of DebugNames and Apple indexes is fixed by
the relevant (pseudo-)standards, so we can't re

[nfc] [lldb] DWARF callbacks: DIERef -> DWARFDIE

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

show more ...

[nfc] [lldb] Introduce DWARF callbacks (fixed-up)

As requested by @labath in https://reviews.llvm.org/D73206#1949516
providing DWARF index callbacks refactorization.

It is a re-landing of the patch

[nfc] [lldb] Introduce DWARF callbacks (fixed-up)

As requested by @labath in https://reviews.llvm.org/D73206#1949516
providing DWARF index callbacks refactorization.

It is a re-landing of the patch with a regression fix the previous
commit had.

Differential Revision: https://reviews.llvm.org/D77327

show more ...

Revert "[nfc] [lldb] Introduce DWARF callbacks"

This reverts commit bd47c470d13b1c57ecf37c1faf0324833d3a4542.

It broke Green Dragon, reason is unknown to me so far:
http://green.lab.llvm.org/gree

Revert "[nfc] [lldb] Introduce DWARF callbacks"

This reverts commit bd47c470d13b1c57ecf37c1faf0324833d3a4542.

It broke Green Dragon, reason is unknown to me so far:
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/15323/consoleFull

Differential Revision: https://reviews.llvm.org/D77327

show more ...

[nfc] [lldb] Introduce DWARF callbacks

As requested by @labath in https://reviews.llvm.org/D73206#1949516
providing DWARF index callbacks refactorization.

Differential Revision: https://reviews.llv

[nfc] [lldb] Introduce DWARF callbacks

As requested by @labath in https://reviews.llvm.org/D73206#1949516
providing DWARF index callbacks refactorization.

Differential Revision: https://reviews.llvm.org/D77327

show more ...

[DebugInfo] Rename getOffset() to getContribution(). NFC.

The old name was a bit misleading because the functions actually return
contributions to the corresponding sections.

Differential revision:

[DebugInfo] Rename getOffset() to getContribution(). NFC.

The old name was a bit misleading because the functions actually return
contributions to the corresponding sections.

Differential revision: https://reviews.llvm.org/D77302

show more ...

[lldb/DWARF] Fix crash when a dwo compile unit refers to a non-dwo type

In this case dwo_num can be None => stop assuming it can't.

[lldb/DWARF] Always construct a DWARFDebugInfo object

Change the return value of SymbolFileDWARF::DebugInfo from a pointer to
a reference, and remove all null checks.

Previously, we were not constr

[lldb/DWARF] Always construct a DWARFDebugInfo object

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).

show more ...

[lldb/DWARF] Re-enable basic dwp support

Summary:
This patch removes the bitrotted SymbolFileDWARF(Dwo)Dwp classes, and
replaces them with dwp support implemented directly inside
SymbolFileDWARFDwo,

[lldb/DWARF] Re-enable basic dwp support

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

show more ...

[lldb/DWARF] Don't hold a unique SymbolFileDWARFDwo in a DWARFUnit

This is the second dwp preparatory patch. When a SymbolFileDWARFDwo will
hold more than one split unit, it will not be able to be u

[lldb/DWARF] Don't hold a unique SymbolFileDWARFDwo in a DWARFUnit

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

show more ...

[lldb/DWARF] Don't assume that a SymbolFileDWARFDwo contains one compile unit

Summary:
This is a preparatory patch to re-enable DWP support in lldb (we already
have code claiming to do that, but it

[lldb/DWARF] Don't assume that a SymbolFileDWARFDwo contains one compile unit

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

show more ...

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73258

show more ...

[lldb/DWARF] Fix mixed v4+v5 location lists

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
leas

[lldb/DWARF] Fix mixed v4+v5 location lists

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

show more ...

[lldb/DWARF] Fix v5 location lists for dwo files

Dwo files don't have a DW_AT_loclists_base -- set one explicitly. Also,
make sure we use the correct location list flavour for v5.

Add RTTI support to the SymbolFile class hierarchy

Differential Revision: https://reviews.llvm.org/D70322

SymbolVendor: Remove the object file member variable

Summary:
The last responsibility of the SymbolVendor was to hold an owning
reference to the object file (in case symbols are being read from a
di

SymbolVendor: Remove the object file member variable

Summary:
The last responsibility of the SymbolVendor was to hold an owning
reference to the object file (in case symbols are being read from a
different file than the main module). As SymbolFile classes already hold
a non-owning reference to the object file, we can easily remove this
responsibility of the SymbolVendor by making the SymbolFile reference
owning.

Reviewers: JDevlieghere, clayborg, jingham

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D65401

llvm-svn: 367392

show more ...

[Symbol] Use llvm::Expected when getting TypeSystems

Summary:
This commit achieves the following:
- Functions used to return a `TypeSystem *` return an
`llvm::Expected<TypeSystem *>` now. This mea

[Symbol] Use llvm::Expected when getting TypeSystems

Summary:
This commit achieves the following:
- Functions used to return a `TypeSystem *` return an
`llvm::Expected<TypeSystem *>` now. This means that the result of a call
is always checked, forcing clients to move more carefully.
- `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a
non-null pointer to a TypeSystem.

Reviewers: JDevlieghere, davide, compnerd

Subscribers: jdoerfert, lldb-commits

Differential Revision: https://reviews.llvm.org/D65122

llvm-svn: 367360

show more ...

DWARF: Add support for type units+split dwarf combo

Summary:
With the last round of refactors, supporting type units in dwo files
becomes almost trivial. This patch contains a couple of small fixes,

DWARF: Add support for type units+split dwarf combo

Summary:
With the last round of refactors, supporting type units in dwo files
becomes almost trivial. This patch contains a couple of small fixes,
which taken as a whole make type units work in the split dwarf scenario
(both DWARF4 and DWARF5):
- DWARFContext: make sure we actually read the debug_types.dwo section
- DWARFUnit: set string offsets base on all units in the dwo file, not
just the main CU
- ManualDWARFIndex: index all units in the file
- SymbolFileDWARFDwo: Search for the single compile unit in the file, as
we can no longer assume it will be the first one

The last part makes it obvious that there is still some work to be done
here, namely that we do not support dwo files with multiple compile
units. That is something that should be easier after the DIERef
refactors, but it still requires more work.

Tests are added for the type units+split dwarf + dwarf4/5 scenarios, as
well as a test that checks we behave reasonably in the presence of dwo
files with multiple CUs.

Reviewers: clayborg, JDevlieghere, aprantl

Subscribers: arphaman, lldb-commits

Differential Revision: https://reviews.llvm.org/D63643

llvm-svn: 364274

show more ...

DWARF: Add "dwo_num" field to the DIERef class

Summary:
When dwo support was introduced, it used a trick where debug info
entries were referenced by the offset of the compile unit in the main
file,

DWARF: Add "dwo_num" field to the DIERef class

Summary:
When dwo support was introduced, it used a trick where debug info
entries were referenced by the offset of the compile unit in the main
file, but the die offset was relative to the dwo file. Although there
was some elegance to it, this representation was starting to reach its
breaking point:
- the fact that the skeleton compile unit owned the DWO file meant that
it was impossible (or at least hard and unintuitive) to support DWO
files containing more than one compile unit. These kinds of files are
produced by LTO for example.
- it made it impossible to reference any DIEs in the skeleton compile
unit (although the skeleton units are generally empty, clang still
puts some info into them with -fsplit-dwarf-inlining).
- (current motivation) it made it very hard to support type units placed
in DWO files, as type units don't have any skeleton units which could
be referenced in the main file

This patch addresses this problem by introducing an new
"dwo_num" field to the DIERef class, whose purpose is to identify the
dwo file. It's kind of similar to the dwo_id field in DWARF5 unit
headers, but while this is a 64bit hash whose main purpose is to catch
file mismatches, this is just a smaller integer used to indentify a
loaded dwo file. Currently, this is based on the index of the skeleton
compile unit which owns the dwo file, but it is intended to be
eventually independent of that (to support the LTO use case).

Simultaneously the cu_offset is dropped to conserve space, as it is no
longer necessary. This means we can remove the "BaseObjectOffset" field
from the DWARFUnit class. It also means we can remove some of the
workarounds put in place to support the skeleton-unit+dwo-die combo.
More work is needed to remove all of them, which is out of scope of this
patch.

Reviewers: JDevlieghere, clayborg, aprantl

Subscribers: mehdi_amini, dexonsmith, arphaman, lldb-commits

Differential Revision: https://reviews.llvm.org/D63428

llvm-svn: 364009

show more ...

DWARF: Provide accessors to DIERef fields

Summary:
Instead of accessing the fields directly, use accessor functions to
provide access to the DIERef components. This allows us to decouple the
externa

DWARF: Provide accessors to DIERef fields

Summary:
Instead of accessing the fields directly, use accessor functions to
provide access to the DIERef components. This allows us to decouple the
external interface, from the internal representation. The external
interface can use llvm::Optional and similar goodies, while the data can
still be stored internally in a more compact representation.

I also document the purpose of the existing DIERef fields.

The main motivation for this change is a need to introduce an additional
field to the DIERef class, but I believe the change has its own merit.

Reviewers: JDevlieghere, aprantl, clayborg

Subscribers: arphaman, lldb-commits

Differential Revision: https://reviews.llvm.org/D63400

llvm-svn: 363910

show more ...

Have DWARFUnit store a *reference* to SymbolFileDWARF

Previously it was storing a *pointer*, which left open the possibility
of this pointer being null. We never made use of that possibility (it
doe

Have DWARFUnit store a *reference* to SymbolFileDWARF

Previously it was storing a *pointer*, which left open the possibility
of this pointer being null. We never made use of that possibility (it
does not make sense), and most of the code was already assuming that.
However, there were a couple of null-checks scattered around the code.

This patch replaces the reference with a pointer, making the
non-null-ness explicit, and removes the remaining null-checks.

llvm-svn: 363381

show more ...

DWARF: Don't create lldb CompileUnits for DWARF type units

Summary:
Type units don't represent actual compilations and a lot of the
operations that we do with lldb compile units (getting their line

DWARF: Don't create lldb CompileUnits for DWARF type units

Summary:
Type units don't represent actual compilations and a lot of the
operations that we do with lldb compile units (getting their line
tables, variables, etc.) don't make sense for them. There is also a lot
more of them (sometimes over 100x), so making them more lightweight pays
off.

The main change in this patch is that we stop creating lldb CompileUnits
for DWARF type units. The trickiest part here is that the SymbolFile
interface requires that we assign consecutive sequence IDs to the
compile units we create. As DWARF type and compile units can come in any
order (in v5), this means we can no longer use 1-1 mapping between DWARF
and lldb compile units. Instead I build a translation table between the
two indices. To avoid pessimizing the case where there are no type
units, I build the translation table only in case we have at least one
type unit.

Additionaly, I also tried to strenghted type safete by replacing
DWARFUnit with DWARFCompileUnit where applicable. Though that was not
stricly necessary, I found it a good way to ensure that the
transformations I am doing here make sense. In the places where I was
changing the function signatures, and where it was obvious that the
objects being handled were not null, I also replaced pointers with
references.

There shouldn't be any major functional change with this patch. The only
change I observed is that now the types in the type units will not be
parsed when one calls Module::ParseAllDebugSymbols, unless they are
referenced from other compile units. This makes sense, given how
ParseAllDebugSymbols is implemented (it iterates over all compile
units), and it only matters for one hand-writted test where I did not
bother to reference the types from the compile units (which I now do).

Reviewers: clayborg, JDevlieghere, aprantl

Subscribers: jdoerfert, lldb-commits

Differential Revision: https://reviews.llvm.org/D63005

llvm-svn: 363250

show more ...

DWARF: Remove cu_idx variables from parsing functions

These variables were useful when looking up the compile unit index
required a binary search. Now that we can look up a compile unit index
in con

DWARF: Remove cu_idx variables from parsing functions

These variables were useful when looking up the compile unit index
required a binary search. Now that we can look up a compile unit index
in constant time, they are no longer needed.

llvm-svn: 361754

show more ...

DWARF: Port debug_addr over to DWARFContext

llvm-svn: 361232

DWARF: Port most of other sections over to DWARFContext

This moves the sections from SymbolFileDWARF to DWARFContext, where it
was trivial to do so. A couple of sections are still left in
SymbolFile

DWARF: Port most of other sections over to DWARFContext

This moves the sections from SymbolFileDWARF to DWARFContext, where it
was trivial to do so. A couple of sections are still left in
SymbolFileDWARF. These will be handled by separate patches.

llvm-svn: 361127

show more ...