Cache the manual DWARF index out to the LLDB cache directory when the LLDB index cache is enabled.

This patch add the ability to cache the manual DWARF indexing results to disk for faster subsequent

Cache the manual DWARF index out to the LLDB cache directory when the LLDB index cache is enabled.

This patch add the ability to cache the manual DWARF indexing results to disk for faster subsequent debug sessions. Manual DWARF indexing is time consuming and causes all DWARF to be fully parsed and indexed each time you debug a binary that doesn't have an acceptable accelerator table. Acceptable accelerator tables include .debug_names in DWARF5 or Apple accelerator tables.

This patch breaks up testing by testing all of the encoding and decoding of required C++ objects in a gtest unit test, and then has a test to verify the debug info cache is generated correctly.

This patch also adds the ability to track when a symbol table or DWARF index is loaded or saved to the cache in the "statistics dump" command. This is essential to know in statistics as it can help explain why a debug session was slower or faster than expected.

Reviewed By: labath, wallace

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

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

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

DWARF: Make DIERefs always valid

Summary:
This patch makes the DIERef class always valid by default constructor
and operator bool. This allows one to express the validity of a DIERef
in the type sys

DWARF: Make DIERefs always valid

Summary:
This patch makes the DIERef class always valid by default constructor
and operator bool. This allows one to express the validity of a DIERef
in the type system. Places which are working with potentially-invalid
DIERefs have been updated to use Optional<DIERef> instead.

The constructor taking a DWARFFormValue was not needed, as all places
which were constructing a DIERef this way were immediately converting it
into a DWARFDIE or a user_id. This can be done without constructing an
intermediate DIERef.

Reviewers: JDevlieghere, clayborg, aprantl

Subscribers: arphaman, lldb-commits

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

llvm-svn: 363767

show more ...

DWARF: Add ability to reference debug info coming from multiple sections

Summary:
This patch adds the ability to precisely address debug info in
situations when a single file can have more than one

DWARF: Add ability to reference debug info coming from multiple sections

Summary:
This patch adds the ability to precisely address debug info in
situations when a single file can have more than one debug-info-bearing
sections (as is the case with type units in DWARF v4).

The changes here can be classified into roughly three categories:
- the code which addresses a debug info by offset gets an additional
argument, which specifies the section one should look into.
- the DIERef class also gets an additional member variable specifying
the section. This way, code dealing with DIERefs can know which
section is the object referring to.
- the user_id_t encoding steals one bit from the dwarf_id field to store
the section. This means the total number of separate object files
(apple .o, or normal .dwo) is limited to 2 billion, but that is fine
as it's not possible to hit that number without switching to DWARF64
anyway.

This patch is functionally equivalent to (and inspired by) the two
patches (D61503 and D61504) by Jan Kratochvil, but there are differences
in the implementation:
- it uses an enum instead of a bool flag to differentiate the sections
- it increases the size of DIERef struct instead of reducing the amount
of addressable debug info
- it sets up DWARFDebugInfo to store the units in a single vector
instead of two. This sets us up for the future in which type units can
also live in the debug_info section, and I believe it's cleaner
because there's no need for unit index remapping

There are no tests with this patch as this is essentially NFC until
we start parsing type units from the debug_types section.

Reviewers: JDevlieghere, clayborg, aprantl

Subscribers: arphaman, jankratochvil, lldb-commits

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

llvm-svn: 360872

show more ...

Permit cross-CU references

So far dw_offset_t was global for the whole SymbolFileDWARF but with
.debug_types the same dw_offset_t may mean two different things depending on
its section (=CU). So ref

Permit cross-CU references

So far dw_offset_t was global for the whole SymbolFileDWARF but with
.debug_types the same dw_offset_t may mean two different things depending on
its section (=CU). So references now return whole new referenced DWARFDIE
instead of just dw_offset_t.

This means that some functions have to now handle 16 bytes instead of 8 bytes
but I do not see that anywhere performance critical.

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

llvm-svn: 360795

show more ...

DWARF: s/CompileUnit/Unit/ in DWARFFormValue

The class has been converted to use DWARFUnit, but a number of uses of
the words compile unit remained. This removes all such references
Get/SetCompileUn

DWARF: s/CompileUnit/Unit/ in DWARFFormValue

The class has been converted to use DWARFUnit, but a number of uses of
the words compile unit remained. This removes all such references
Get/SetCompileUnit becomes Get/SetUnit, and m_cu becomes m_unit.

llvm-svn: 360754

show more ...

[DWARF] Centralize user_id <-> DWARFDIE conversions

Summary:
The logic for translating a user_id into a DWARFDIE was replicated in
several places. This removes that redundancy and settles on a singl

[DWARF] Centralize user_id <-> DWARFDIE conversions

Summary:
The logic for translating a user_id into a DWARFDIE was replicated in
several places. This removes that redundancy and settles on a single
implementation in SymbolFileDWARF.

The reason for choosing that instead of DIERef was that we were
always immediately converting the returned DIERef into a DWARFDIE
anyway, which meant that one had to specify the SymbolFileDWARF argument
twice (once to get the DIERef, and once to get the actual DIE). Also,
passing a higher-level object (SymbolFileDWARF) into a lower-level one
(DIERef) seemed like a less intuitive arrangement than doing things the
other way around.

Reviewers: JDevlieghere, clayborg, aprantl

Subscribers: tberghammer, jankratochvil, lldb-commits

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

llvm-svn: 360246

show more ...

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.

I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.

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

llvm-svn: 358135

show more ...

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

DIERef: move trivial constructors into the header

This enables more inlining/optimization opportunities for a fairly
critical class.

NFCI

llvm-svn: 334198

Move the codebase to use: DWARFCompileUnit -> DWARFUnit

Now the codebase can use the DWARFUnit superclass. It will make it later
seamlessly work also with DWARFPartialUnit for DWZ.

This patch is on

Move the codebase to use: DWARFCompileUnit -> DWARFUnit

Now the codebase can use the DWARFUnit superclass. It will make it later
seamlessly work also with DWARFPartialUnit for DWZ.

This patch is only a search-and-replace easily undone, nothing interesting
in it.

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

llvm-svn: 327810

show more ...

Prevent vain lldb::user_id_t 0xffffffff lookups

I have found LLDB commonly looks up lldb::user_id_t 0xffffffff failing to find
its DIE. One would rather expect LLDB_INVALID_UID == 0xffffffffffffffff

Prevent vain lldb::user_id_t 0xffffffff lookups

I have found LLDB commonly looks up lldb::user_id_t 0xffffffff failing to find
its DIE. One would rather expect LLDB_INVALID_UID == 0xffffffffffffffff in such
case.

DWARFASTParserClang.cpp:495
492 type_sp.reset(
493 new Type(die.GetID(), dwarf, type_name_const_str, byte_size, NULL,
494 DIERef(encoding_uid).GetUID(dwarf), encoding_data_type,
495 &decl, clang_type, resolve_state));
encoding_uid = (DWARFFormValue) {m_cu = 0x0, m_form = 0, m_value = {value = {uval = 0, sval = 0, cstr = 0x0}, data = 0x0}}
-> DIERef::DIERef(const DWARFFormValue &form_value = {m_cu = 0x0, m_form = 0, m_value = {value = {uval = 0, sval = 0, cstr = 0x0}, data = 0x0}})
-> (DIERef) {cu_offset = 0xffffffff, die_offset = 0xffffffff}
-> lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf = 0x61d00000b480) const
-> Type::Type(lldb::user_id_t encoding_uid = 0xffffffff)
But 0xffffffff !=
#define LLDB_INVALID_UID UINT64_MAX

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

llvm-svn: 319580

show more ...

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging t

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.

llvm-svn: 280751

show more ...

When support for DWO files was added, there were two ways to pass lldb::user_id_t out to the rest of LLDB:
1 - DWARF in .o files with debug map in executable: we would place the compile unit index in

When support for DWO files was added, there were two ways to pass lldb::user_id_t out to the rest of LLDB:
1 - DWARF in .o files with debug map in executable: we would place the compile unit index in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset
2 - DWO: we would place the compile unit offset in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset

There was a mixing and matching of this and it wasn't done consistently.

Major changes include:

The DIERef constructor that takes a lldb::user_id_t now requires a SymbolFileDWARF:

DIERef(lldb::user_id_t uid, SymbolFileDWARF *dwarf)

It is needed so that it can be decoded correctly. If it is DWARF in .o files with debug map in executable, then we get the right compile unit from the SymbolFileDWARFDebugMap, otherwise, we use the compile unit offset and DIE offset for DWO or normal DWARF.

The function:

lldb::user_id_t DIERef::GetUID() const;

Now becomes

lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf) const;

Again, we need the DWARF file to encode it correctly.

This removes the need for "lldb::user_id_t SymbolFileDWARF::MakeUserID() const" and for bool SymbolFileDWARF::UserIDMatches (lldb::user_id_t uid) const". There were also many places were doing things inneficiently like:

1 - encode a dw_offset_t into a lldb::user_id_t
2 - call the public SymbolFile interface to resolve types using the lldb::user_id_t
3 - This would then decode the lldb::user_id_t into a DIERef, and then try to find that type.

There are many places that are now doing this more efficiently by storing DW_AT_type form values as DWARFFormValue objects and then making a DIERef from them and directly calling the underlying function to resolve the lldb_private::Type, lldb_private::CompilerType, lldb_private::CompilerDecl, lldb_private::CompilerDeclContext.

If there are any regressions in DWARF with DWO, we will need to fix any issues that arise since the original patch wasn't functional for the much more widely used DWARF in .o files with debug map.

<rdar://problem/25200976>

llvm-svn: 264909

show more ...

Add basic fission support to SymbolFileDWARF

* Create new dwo symbol file class
* Add handling for .dwo sections
* Change indexes in SymbolFileDWARF to store compile unit offset next to
DIE offset

Add basic fission support to SymbolFileDWARF

* Create new dwo symbol file class
* Add handling for .dwo sections
* Change indexes in SymbolFileDWARF to store compile unit offset next to
DIE offset
* Propagate queries from dwarf compile unit to the dwo compile unit
where applicable

Differential revision: http://reviews.llvm.org/D12291

llvm-svn: 247132

show more ...