[nfc] [lldb] Move LookupAddress to DWARFCompileUnit

LookupAddress makes no sense for DWARFTypeUnit.
Also make GetNonSkeletonUnit to preserve the called type.

Differential Revision: https://reviews.

[nfc] [lldb] Move LookupAddress to DWARFCompileUnit

LookupAddress makes no sense for DWARFTypeUnit.
Also make GetNonSkeletonUnit to preserve the called type.

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

show more ...

[lldb/DWARF] Trust CU DW_AT_low/high_pc information when building address tables

Summary:
The code in DWARFCompileUnit::BuildAddressRangeTable tries hard to avoid
relying on DW_AT_low/high_pc for co

[lldb/DWARF] Trust CU DW_AT_low/high_pc information when building address tables

Summary:
The code in DWARFCompileUnit::BuildAddressRangeTable tries hard to avoid
relying on DW_AT_low/high_pc for compile unit range information, and
this logic is a big cause of llvm/lldb divergence in the lowest layers
of dwarf parsing code.

The implicit assumption in that code is that this information (as opposed to
DW_AT_ranges) is unreliable. However, I have not been able to verify
that assumption. It is definitely not true for all present-day
compilers (gcc, clang, icc), and it was also not the case for the
historic compilers that I have been able to get a hold of (thanks Matt
Godbolt).

All compiler included in my research either produced correct
DW_AT_ranges or .debug_aranges entries, or they produced no DW_AT_hi/lo
pc at all. The detailed findings are:
- gcc >= 4.4: produces DW_AT_ranges and .debug_aranges
- 4.1 <= gcc < 4.4: no DW_AT_ranges, no DW_AT_high_pc, .debug_aranges
present. The upper version range here is uncertain as godbolt.org does
not have intermediate versions.
- gcc < 4.1: no versions on godbolt.org
- clang >= 3.5: produces DW_AT_ranges, and (optionally) .debug_aranges
- 3.4 <= clang < 3.5: no DW_AT_ranges, no DW_AT_high_pc, .debug_aranges
present.
- clang <= 3.3: no DW_AT_ranges, no DW_AT_high_pc, no .debug_aranges
- icc >= 16.0.1: produces DW_AT_ranges
- icc < 16.0.1: no functional versions on godbolt.org (some are present
but fail to compile)

Based on this analysis, I believe it is safe to start trusting
DW_AT_low/high_pc information in dwarf as well as remove the code for
manually reconstructing range information by traversing the DIE
structure, and just keep the line table fallback. The only compilers
where this will change behavior are pre-3.4 clangs, which are almost 7
years old now. However, the functionality should remain unchanged
because we will be able to reconstruct this information from the line
table, which seems to be needed for some line-tables-only scenarios
anyway (haven't researched this too much, but at least some compilers
seem to emit DW_AT_ranges even in these situations).

In addition, benchmarks showed that for these compilers computing the
ranges via line tables is noticably faster than doing so via the DIE
tree.

Other advantages include simplifying the code base, removing some
untested code (the only test changes are recent tests with overly
reduced synthetic dwarf), and increasing llvm convergence.

Tags: #lldb

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

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

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: Don't compute address ranges for type units

Summary:
Type units don't describe any code, so they should never be the result
of any address lookup queries.

Previously, we would compute the ad

DWARF: Don't compute address ranges for type units

Summary:
Type units don't describe any code, so they should never be the result
of any address lookup queries.

Previously, we would compute the address ranges for the type units for
via the line tables they reference because the type units looked a lot
like line-tables-only compile units. However, this is not correct, as
the line tables are only referenced from type units so that other
declarations can use the file names contained in them.

In this patch I make the BuildAddressRangeTable function virtual, and
implement it only for compile units.

Testing this was a bit tricky, because the behavior depends on the order
in which we add things to the address range map. This rarely caused a
problem with DWARF v4 type units, as they are always added after all
CUs. It happened more frequently with DWARF v5, as there clang emits the
type units first. However, this is still not something that it is
required to do, so for testing I've created an assembly file where I've
deliberately sandwiched a compile unit between two type units, which
should isolate us from both changes in how the compiler emits the units
and changes in the order we process them.

Reviewers: clayborg, aprantl, JDevlieghere

Subscribers: jdoerfert, lldb-commits

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

llvm-svn: 361465

show more ...

DWARF: Introduce DWARFUnitHeader class

Summary:
This patch introduces the DWARFUnitHeader class. Its purpose (and its
structure, to the extent it was possible to make it) is the same as its
LLVM cou

DWARF: Introduce DWARFUnitHeader class

Summary:
This patch introduces the DWARFUnitHeader class. Its purpose (and its
structure, to the extent it was possible to make it) is the same as its
LLVM counterpart -- to extract the unit header information before we
actually construct the unit, so that we know which kind of units to
construct. This is needed because as of DWARF5, type units live in the
.debug_info section, which means it's not possible to statically
determine the type of units in a given section.

Reviewers: aprantl, clayborg, JDevlieghere

Subscribers: lldb-commits

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

llvm-svn: 361224

show more ...

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

Make DWARFContext dwo-aware and port debug_info sections over

Summary:
The previous attempt and moving section handling over to DWARFContext
(D59611) failed because it did not take into account the

Make DWARFContext dwo-aware and port debug_info sections over

Summary:
The previous attempt and moving section handling over to DWARFContext
(D59611) failed because it did not take into account the dwo sections
correctly. All DWARFContexts (even those in SymbolFileDWARFDwo) used the
main module for loading the sections, but in the dwo scenario some
sections should come from the dwo file.

This patch fixes that by making the DWARFContext aware of whether it a
dwo context or a regular one. A dwo context gets two sections lists, and
it knows where to look for a particular type of a section. This isn't
fully consistent with how the llvm DWARFContext behaves, because that
one leaves it up to the user to know whether it should ask for a dwo
section or not. However, for the time being, it seems useful to have a
single entity which knows how to peice together the debug info in dwo
and non-dwo scenarios. The rough roadmap for the future is:
- port over the rest of the sections to DWARFContext
- find a way to get rid of SymbolFileDWARFDwo/Dwp/DwpDwo. This will
likely involve adding the ability for the DWARFContext to spawn
dwo sub-contexts, similarly to how it's done in llvm.
- get rid of the special handling of the "dwo" contexts by making
sure everything knows whether it should ask for the .dwo version of
the section or not (similarly to how llvm's DWARFUnits do that)

To demonstrate how the DWARFContext should behave in this new world, I
port the debug_info section (which is debug_info.dwo in the dwo file)
handling to DWARFContext. The rest of the sections will come in
subsequent patches.

Reviewers: aprantl, clayborg, JDevlieghere

Subscribers: zturner, lldb-commits

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

llvm-svn: 361000

show more ...

Finish renaming CompileUnit -> Unit

D42892 changed a lot of code to use superclass DWARFUnit instead of its
subclass DWARFCompileUnit.

Finish this change more thoroughly for any *CompileUnit* -> *U

Finish renaming CompileUnit -> Unit

D42892 changed a lot of code to use superclass DWARFUnit instead of its
subclass DWARFCompileUnit.

Finish this change more thoroughly for any *CompileUnit* -> *Unit* names.
Later patch will introduce DWARFTypeUnit which needs to be sometimes different
from DWARFCompileUnit and it would be confusing without this renaming.

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

llvm-svn: 360443

show more ...

[DWARF] Reimplement/simplify DWARFUnit::GetID

Summary:
The implementation of GetID used a relatively complicated algorithm,
which returned some kind of an offset of the unit in some file
(depending

[DWARF] Reimplement/simplify DWARFUnit::GetID

Summary:
The implementation of GetID used a relatively complicated algorithm,
which returned some kind of an offset of the unit in some file
(depending on the debug info flavour). The only thing this ID was used
for was to enable subseqent retrieval of the unit from the SymbolFile.

This can be made simpler if we just make the "ID" of the unit an index
into the list of the units belonging to the symbol file. We already
support indexed access to the units, so each unit already has a well
"index" -- this just makes it accessible from within the unit.

To make the distincion between "id" and "offset" clearer (and help catch
any misuses), I also rename DWARFDebugInfo::GetCompileUnit (which
accesses by offset) into DWARFDebugInfo::GetCompileUnitAtOffset.

On its own, this only brings a minor simplification, but it enables
further simplifications in the DIERef class (coming in a follow-up
patch).

Reviewers: JDevlieghere, clayborg, aprantl

Subscribers: arphaman, jdoerfert, lldb-commits, tberghammer, jankratochvil

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

llvm-svn: 360014

show more ...

Revert "Move the rest of the sections over to DWARFContext."

This reverts commit r356682 because it breaks the DWO flavours of some
tests:
lldb-Suite :: lang/c/const_variables/TestConstVariables

Revert "Move the rest of the sections over to DWARFContext."

This reverts commit r356682 because it breaks the DWO flavours of some
tests:
lldb-Suite :: lang/c/const_variables/TestConstVariables.py
lldb-Suite :: lang/c/local_variables/TestLocalVariables.py
lldb-Suite :: lang/c/vla/TestVLA.py

llvm-svn: 356773

show more ...

Move the rest of the sections over to DWARFContext.

This is mostly mechanical, and just moves the remaining non-DWO
related sections over to DWARFContext.

Differential Revision: https://reviews.llv

Move the rest of the sections over to DWARFContext.

This is mostly mechanical, and just moves the remaining non-DWO
related sections over to DWARFContext.

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

llvm-svn: 356682

show more ...

Return Error and Expected from more DWARF interfaces.

This continues the work of introducing Error and Expected into
the DWARF parsing interfaces, this time for the DWARFCompileUnit
and DWARFDebugAr

Return Error and Expected from more DWARF interfaces.

This continues the work of introducing Error and Expected into
the DWARF parsing interfaces, this time for the DWARFCompileUnit
and DWARFDebugAranges classes.

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

llvm-svn: 356278

show more ...

Remove support for DWARF64.

LLVM doesn't produce DWARF64, and neither does GCC. LLDB's support
for DWARF64 is only partial, and if enabled appears to also not work.
Finally, it's untested. Removin

Remove support for DWARF64.

LLVM doesn't produce DWARF64, and neither does GCC. LLDB's support
for DWARF64 is only partial, and if enabled appears to also not work.
Finally, it's untested. Removing this makes merging LLVM and
LLDB's DWARF parsing implementations simpler.

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

llvm-svn: 355975

show more ...

Remove unused extern declaration as removed by D32167

llvm-svn: 354225

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[LLDB] - Improved DWARF5 support.

This patch improves the support of DWARF5.
Particularly the reporting of source code locations.

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

llvm-svn: 3

[LLDB] - Improved DWARF5 support.

This patch improves the support of DWARF5.
Particularly the reporting of source code locations.

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

llvm-svn: 342153

show more ...

Reland "[DWARF] Extract indexing code into a separate class hierarchy"

After this commit, the xcode project will need to be updated to include
the new files added here.

llvm-svn: 332841

Revert "[DWARF] Extract indexing code into a separate class hierarchy"

This reverts commit r332719 due to breaking this green dragon build:
http://green.lab.llvm.org/green/job/lldb-xcode/6644

llvm-

Revert "[DWARF] Extract indexing code into a separate class hierarchy"

This reverts commit r332719 due to breaking this green dragon build:
http://green.lab.llvm.org/green/job/lldb-xcode/6644

llvm-svn: 332730

show more ...

[DWARF] Extract indexing code into a separate class hierarchy

Summary:
This places the `if(m_using_apple_tables)` branches inside the
SymbolFileDWARF class behind an abstract DWARFIndex class. The c

[DWARF] Extract indexing code into a separate class hierarchy

Summary:
This places the `if(m_using_apple_tables)` branches inside the
SymbolFileDWARF class behind an abstract DWARFIndex class. The class
currently has two implementations:
- AppleIndex, which searches using .apple_names and friends
- ManualIndex, which searches using a manually built index

Most of the methods of the class are very simple, and simply extract the
list of DIEs for the given name from the appropriate sub-table. The main
exception are the two GetFunctions overloads, which take a couple of
extra paramenters, including some callbacks. It was not possible to
split these up the same way as other methods, as here we were doing a
lot of post-processing on the results. The post-processing is similar
for the two cases, but not identical. I hope to factor these further in
separate patches.

Other interesting methods are:
- Preload(): do any preprocessing to make lookups faster (noop for
AppleIndex, forces a build of the lookup tables for ManualIndex).
- ReportInvalidDIEOffset(): Used to notify the users of an invalid index
(prints a message for AppleIndex, noop for ManualIndex).
- Dump(): dumps the index state (noop for AppleIndex, prints the lookup
tables for ManualIndex).

Reviewers: clayborg, JDevlieghere

Subscribers: mgorny, aprantl, lldb-commits

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

llvm-svn: 332719

show more ...

General cleanup to minimize the .debug_types patch

This cleanup is designed to make the https://reviews.llvm.org/D32167 patch smaller and easier to read.

Cleanup in this patch:

Allow DWARFUnit sub

General cleanup to minimize the .debug_types patch

This cleanup is designed to make the https://reviews.llvm.org/D32167 patch smaller and easier to read.

Cleanup in this patch:

Allow DWARFUnit subclasses to hand out the data that should be used when decoding data for a DIE. The information might be in .debug_info or could be in .debug_types. There is a new virtual function on DWARFUnit that each subclass must override:

virtual const lldb_private::DWARFDataExtractor &DWARFUnit::GetData() const;
This allows DWARFCompileUnit and eventually DWARFTypeUnit to hand out different data to be used when decoding the DIE information.

Add a new pure virtual function to get the size of the DWARF unit header:

virtual uint32_t DWARFUnit::GetHeaderByteSize() const = 0;
This allows DWARFCompileUnit and eventually DWARFTypeUnit to hand out different offsets where the first DIE starts when decoding DIE information from the unit.

Added a new function to DWARFDataExtractor to get the size of an offset:

size_t DWARFDataExtractor::GetDWARFSizeOfOffset() const;
Removed dead dumping and parsing code in the DWARFDebugInfo class.
Inlined a bunch of calls in DWARFUnit for accessors that were just returning integer member variables.
Renamed DWARFUnit::Size() to DWARFUnit::GetHeaderByteSize() as it clearly states what it is doing and makes more sense.

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

llvm-svn: 331892

show more ...

Reapply "Cleanup DWARFCompileUnit and DWARFUnit in preparation for adding DWARFTypeUnit".

This patch by Greg Clayton drops the virtualization for DWARFPartialUnit.
The virtualization of DWARFUnit no

Reapply "Cleanup DWARFCompileUnit and DWARFUnit in preparation for adding DWARFTypeUnit".

This patch by Greg Clayton drops the virtualization for DWARFPartialUnit.
The virtualization of DWARFUnit now matches more its LLVM counterpart.
DWZ patchset is going to be implementable without DWARFPartialUnit remapping.
https://reviews.llvm.org/D40474

This reverts commit 329423.
This reapplies commit r329305.

llvm-svn: 330084

show more ...

Revert "Cleanup DWARFCompileUnit and DWARFUnit in preparation for adding DWARFTypeUnit"

The reverted commit changed DWARFUnit from https://reviews.llvm.org/D40466 and
https://reviews.llvm.org/D42892

Revert "Cleanup DWARFCompileUnit and DWARFUnit in preparation for adding DWARFTypeUnit"

The reverted commit changed DWARFUnit from https://reviews.llvm.org/D40466 and
https://reviews.llvm.org/D42892 that was prepared for DWARFPartialUnit and
made from it a superclass for DWARFTypeUnit. DWARFUnit's intention was:
DWARFUnit->DWARFSomeNameUnit->DWARFCompileUnit
DWARFUnit->DWARFSomeNameUnit->DWARFTypeUnit
DWARFUnit->DWARFPartialUnit

Discussed at: https://reviews.llvm.org/D45170

This reverts commit r329305.

llvm-svn: 329423

show more ...

Cleanup DWARFCompileUnit and DWARFUnit in preparation for adding DWARFTypeUnit

Many things that were in DWARFCompileUnit actually need to be in DWARFUnit. This patch moves all DWARFUnit specific thi

Cleanup DWARFCompileUnit and DWARFUnit in preparation for adding DWARFTypeUnit

Many things that were in DWARFCompileUnit actually need to be in DWARFUnit. This patch moves all DWARFUnit specific things over into DWARFUnit and fixes the layering. This is in preparation for adding DWARFTypeUnit for the .debug_types patch.

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

llvm-svn: 329305

show more ...