Use the range-based overload of llvm::sort where possible

Reviewed By: MaskRay

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

Don't use Optional::hasValue (NFC)

[lldb] Use value_or instead of getValueOr (NFC)

Introduce new symbol on-demand for debug info

This diff introduces a new symbol on-demand which skips
loading a module's debug info unless explicitly asked on
demand. This provides significant perfo

Introduce new symbol on-demand for debug info

This diff introduces a new symbol on-demand which skips
loading a module's debug info unless explicitly asked on
demand. This provides significant performance improvement
for application with dynamic linking mode which has large
number of modules.
The feature can be turned on with:
"settings set symbols.load-on-demand true"

The feature works by creating a new SymbolFileOnDemand class for
each module which wraps the actual SymbolFIle subclass as member
variable. By default, most virtual methods on SymbolFileOnDemand are
skipped so that it looks like there is no debug info for that module.
But once the module's debug info is explicitly requested to
be enabled (in the conditions mentioned below) SymbolFileOnDemand
will allow all methods to pass through and forward to the actual SymbolFile
which would hydrate module's debug info on-demand.

In an internal benchmark, we are seeing more than 95% improvement
for a 3000 modules application.

Currently we are providing several ways to on demand hydrate
a module's debug info:
* Source line breakpoint: matching in supported files
* Stack trace: resolving symbol context for an address
* Symbolic breakpoint: symbol table match guided promotion
* Global variable: symbol table match guided promotion

In all above situations the module's debug info will be on-demand
parsed and indexed.

Some follow-ups for this feature:
* Add a command that allows users to load debug info explicitly while using a
new or existing command when this feature is enabled
* Add settings for "never load any of these executables in Symbols On Demand"
that takes a list of globs
* Add settings for "always load the the debug info for executables in Symbols
On Demand" that takes a list of globs
* Add a new column in "image list" that shows up by default when Symbols On
Demand is enable to show the status for each shlib like "not enabled for
this", "debug info off" and "debug info on" (with a single character to
short string, not the ones I just typed)

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

show more ...

[lldb] Return all line entries matchign a line if no column is specified

Previously, if no column was specified, ResolveSymbolContext would take
the first match returned by FindLineEntryIndexByFileI

[lldb] Return all line entries matchign a line if no column is specified

Previously, if no column was specified, ResolveSymbolContext would take
the first match returned by FindLineEntryIndexByFileIndex, and reuse it
to find subsequent exact matches. With the introduction of columns, columns
are now considered when matching the line entries.

This leads to a problem if one wants to get all existing line entries
that match that line, since now the column is also used for the exact match.
This way, all line entries are filtered out that have a different
column number, but the same line number.

This patch changes that by ignoring the column information of the first match
if the original request of ResolveSymbolContext was also ignoring it.

Reviewed By: mib

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

show more ...

[nfc] [lldb] Support moving support files instead of copy

Split from D100299.

Reviewed By: jankratochvil

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

[lldb] [DWARF-5] Be lazier about loading .dwo files

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
suppo

[lldb] [DWARF-5] Be lazier about loading .dwo files

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

show more ...

Revert "[lldb] [DWARF-5] Be lazier about loading .dwo files"

This reverts commit 8dfd6cae9bd62ae5ef056b994ece2e98f1558830.

This change broke the windows lldb bot:
https://lab.llvm.org/buildbot/#/bu

Revert "[lldb] [DWARF-5] Be lazier about loading .dwo files"

This reverts commit 8dfd6cae9bd62ae5ef056b994ece2e98f1558830.

This change broke the windows lldb bot:
https://lab.llvm.org/buildbot/#/builders/83/builds/8842

show more ...

[lldb] [DWARF-5] Be lazier about loading .dwo files

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
suppo

[lldb] [DWARF-5] Be lazier about loading .dwo files

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

show more ...

Revert "[lldb] [DWARF-5] Be lazier about loading .dwo files"

This reverts commit e7b8ba103a8411fb25237727c3822d4c431e4814.

It broke 32-bit ARM - lldb-arm-ubuntu, reported by omjavaid:
https://lab

Revert "[lldb] [DWARF-5] Be lazier about loading .dwo files"

This reverts commit e7b8ba103a8411fb25237727c3822d4c431e4814.

It broke 32-bit ARM - lldb-arm-ubuntu, reported by omjavaid:
https://lab.llvm.org/buildbot/#/builders/17/builds/9595

show more ...

[lldb] [DWARF-5] Be lazier about loading .dwo files

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
suppo

[lldb] [DWARF-5] Be lazier about loading .dwo files

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

show more ...

[lldb] Refactor argument group by SourceLocationSpec (NFCI)

This patch refactors a good part of the code base turning the usual
FileSpec, Line, Column, CheckInlines, ExactMatch arguments into a
Sour

[lldb] Refactor argument group by SourceLocationSpec (NFCI)

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 <[email protected]>

show more ...

[lldb] Use CompileUnit::ResolveSymbolContext in SymbolFileDWARF

SymbolFileDWARF::ResolveSymbolContext is currently unaware that in DWARF5 the primary file is specified at file index 0. As a result i

[lldb] Use CompileUnit::ResolveSymbolContext in SymbolFileDWARF

SymbolFileDWARF::ResolveSymbolContext is currently unaware that in DWARF5 the primary file is specified at file index 0. As a result it misses to correctly resolve the symbol context for the primary file when DWARF5 debug data is used and the primary file is only specified at index 0.

This change makes use of CompileUnit::ResolveSymbolContext to resolve the symbol context. The ResolveSymbolContext in CompileUnit has been previously already updated to reflect changes in DWARF5
and contains a more readable version. It can resolve more, but will also do a bit more work than
SymbolFileDWARF::ResolveSymbolContext (getting the Module, and going through SymbolFileDWARF::ResolveSymbolContextForAddress), however, it's mostly directed by $resolve_scope
what will be resolved, and ensures that code is easier to maintain if there's only one path.

Reviewed By: labath

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

show more ...

[lldb] Abstract scoped timer logic behind LLDB_SCOPED_TIMER (NFC)

This patch introduces a LLDB_SCOPED_TIMER macro to hide the needlessly
repetitive creation of scoped timers in LLDB. It's similar to

[lldb] Abstract scoped timer logic behind LLDB_SCOPED_TIMER (NFC)

This patch introduces a LLDB_SCOPED_TIMER macro to hide the needlessly
repetitive creation of scoped timers in LLDB. It's similar to the
LLDB_LOG(F) macro.

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

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] Don't put compile unit name into the support file list and support DWARF5 line tables

Summary:
Lldb's "format-independent" debug info made use of the fact that DWARF
(<=4) did not use the fil

[lldb] Don't put compile unit name into the support file list and support DWARF5 line tables

Summary:
Lldb's "format-independent" debug info made use of the fact that DWARF
(<=4) did not use the file index zero, and reused the support file index
zero for storing the compile unit name.

While this provided some convenience for DWARF<=4, it meant that the PDB
plugin needed to artificially remap file indices in order to free up
index 0. Furthermore, DWARF v5 make file index 0 legal, which meant that
similar remapping would be needed in the dwarf plugin too.

What this patch does instead is remove the requirement of having the
compile unit name in the index 0. It is not that useful since the name
can always be fetched from the CompileUnit object. Remapping code in the
pdb plugin(s) has been removed or simplified.

DWARF plugin has started inserting an empty FileSpec at index 0 to
ensure the indices keep matching up (in case of DWARF<=4). For DWARF5,
we insert the file 0 from the line table.

I add a test to ensure we can correctly lookup line table entries
referencing file 0, and in particular the case where the file 0 is also
duplicated in another file entry, as this is how clang produces line
tables in some circumstances (see pr44170). Though this is probably a
bug in clang, this is not forbidden by DWARF, and lldb already has
support for that in some (but not all) cases -- this adds a test for the
code path which was not fixed in this patch.

Reviewers: clayborg, JDevlieghere, jdoerfert

Subscribers: aprantl, lldb-commits

Tags: #lldb

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

show more ...

[lldb] s/FileSpec::Equal/FileSpec::Match

Summary:
The FileSpec class is often used as a sort of a pattern -- one specifies
a bare file name to search, and we check if in matches the full file
name o

[lldb] s/FileSpec::Equal/FileSpec::Match

Summary:
The FileSpec class is often used as a sort of a pattern -- one specifies
a bare file name to search, and we check if in matches the full file
name of an existing module (for example).

These comparisons used FileSpec::Equal, which had some support for it
(via the full=false argument), but it was not a good fit for this job.

For one, it did a symmetric comparison, which makes sense for a function
called "equal", but not for typical searches (when searching for
"/foo/bar.so", we don't want to find a module whose name is just
"bar.so"). This resulted in patterns like:
if (FileSpec::Equal(pattern, file, pattern.GetDirectory()))
which would request a "full" match only if the pattern really contained
a directory. This worked, but the intended behavior was very unobvious.

On top of that, a lot of the code wanted to handle the case of an
"empty" pattern, and treat it as matching everything. This resulted in
conditions like:
if (pattern && !FileSpec::Equal(pattern, file, pattern.GetDirectory())
which are nearly impossible to decipher.

This patch introduces a FileSpec::Match function, which does exactly
what most of FileSpec::Equal callers want, an asymmetric match between a
"pattern" FileSpec and a an actual FileSpec. Empty paterns match
everything, filename-only patterns match only the filename component.

I've tried to update all callers of FileSpec::Equal to use a simpler
interface. Those that hardcoded full=true have been changed to use
operator==. Those passing full=pattern.GetDirectory() have been changed
to use FileSpec::Match.

There was also a handful of places which hardcoded full=false. I've
changed these to use FileSpec::Match too. This is a slight change in
semantics, but it does not look like that was ever intended, and it was
more likely a result of a misunderstanding of the "proper" way to use
FileSpec::Equal.

[In an ideal world a "FileSpec" and a "FileSpec pattern" would be two
different types, but given how widespread FileSpec is, it is unlikely
we'll get there in one go. This at least provides a good starting point
by centralizing all matching behavior.]

Reviewers: teemperor, JDevlieghere, jdoerfert

Subscribers: emaste, lldb-commits

Tags: #lldb

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

show more ...

[lldb] Remove FileSpec->CompileUnit inheritance

Summary:
CompileUnit is a complicated class. Having it be implicitly convertible
to a FileSpec makes reasoning about it even harder.

This patch repla

[lldb] Remove FileSpec->CompileUnit inheritance

Summary:
CompileUnit is a complicated class. Having it be implicitly convertible
to a FileSpec makes reasoning about it even harder.

This patch replaces the inheritance by a simple member and an accessor
function. This avoid the need for casting in places where one needed to
force a CompileUnit to be treated as a FileSpec, and does not add much
verbosity elsewhere.

It also fixes a bug where we were wrongly comparing CompileUnit& and a
CompileUnit*, which compiled due to a combination of this inheritance
and the FileSpec*->FileSpec implicit constructor.

Reviewers: teemperor, JDevlieghere, jdoerfert

Subscribers: lldb-commits

Tags: #lldb

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

show more ...

[lldb] NFC: refactor CompileUnit::ResolveSymbolContext

Summary:
I found the above named method hard to read because it had

a) many nested blocks,
b) one return statement at the end with some logic

[lldb] NFC: refactor CompileUnit::ResolveSymbolContext

Summary:
I found the above named method hard to read because it had

a) many nested blocks,
b) one return statement at the end with some logic involved,
c) a duplicated while-loop with just small differences in it.

I decided to refactor this function by employing an early exit strategy.
In order to capture the logic in the return statement and to not have it
repeated more than once I chose to implement a very small lamda function
that captures all the variables it needs.
I also replaced the two while-loops with just one.

This is a non-functional change (NFC).

Reviewers: jdoerfert, teemperor

Reviewed By: teemperor

Subscribers: labath, teemperor, lldb-commits

Tags: #lldb

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

show more ...

Revert "[lldb] NFC: refactor CompileUnit::ResolveSymbolContext"

This reverts commit 373e2a4f69d623e59329ff801f261d8b299e12d2.

This broke breakpoint setting.

[lldb] NFC: refactor CompileUnit::ResolveSymbolContext

Summary:
I found the above named method hard to read because it had

a) many nested blocks and
b) one return statement at the end with some log

[lldb] NFC: refactor CompileUnit::ResolveSymbolContext

Summary:
I found the above named method hard to read because it had

a) many nested blocks and
b) one return statement at the end with some logic involved.

I decided to refactor this function by employing an early exit strategy.
In order to capture the logic in the return statement and to not have it
repeated more than once I chose to implement a very small lamda function
that captures all the variables it needs.

This is a non-functional change (NFC).

Reviewers: jdoerfert

Subscribers: lldb-commits

Tags: #lldb

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

show more ...

Use ForEachExternalModule in ParseTypeFromClangModule (NFC)

I wanted to further simplify ParseTypeFromClangModule by replacing the
hand-rolled loop with ForEachExternalModule, and then realized that

Use ForEachExternalModule in ParseTypeFromClangModule (NFC)

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

show more ...

[LLDB][Formatters] Re-enable std::function formatter with fixes to improve non-cached lookup performance

Performance issues lead to the libc++ std::function formatter to be disabled. We addressed so

[LLDB][Formatters] Re-enable std::function formatter with fixes to improve non-cached lookup performance

Performance issues lead to the libc++ std::function formatter to be disabled. We addressed some of those performance issues by adding caching see D67111
This PR fixes the first lookup performance by not using FindSymbolsMatchingRegExAndType(...) and instead finding the compilation unit the std::function wrapped callable should be in and then searching for the callable directly in the CU.

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

show more ...

[lldb] Decouple importing the std C++ module from the way the program is compiled

Summary:
At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the

[lldb] Decouple importing the std C++ module from the way the program is compiled

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

show more ...

[DWARF} Use LLVM's debug line parser in LLDB.

The line number table header was substantially revised in DWARF 5 and is
not fully supported by LLDB's current debug line implementation.

This patch re

[DWARF} Use LLVM's debug line parser in LLDB.

The line number table header was substantially revised in DWARF 5 and is
not fully supported by LLDB's current debug line implementation.

This patch replaces the LLDB debug line parser with its counterpart in
LLVM. This was possible because of the limited contact surface between
the code to parse the DWARF debug line section and the rest of LLDB.

We pay a small cost in terms of performance and memory usage. This is
something we plan to address in the near future.

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

llvm-svn: 368742

show more ...