Refactor protected virtual functions from SymbolFile into new SymbolFileCommon class.

This is a preparatory patch for https://reviews.llvm.org/D121631.
It refactors protected virtual members of Symb

Refactor protected virtual functions from SymbolFile into new SymbolFileCommon class.

This is a preparatory patch for https://reviews.llvm.org/D121631.
It refactors protected virtual members of SymbolFile
into a new SymbolFileCommon class per suggestion in:
https://reviews.llvm.org/D121631

This will avoid the friendship declaration in that patch.

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

show more ...

Fix a double debug info size counting in top level stats for "statistics dump".

This mainly affects Darwin targets (macOS, iOS, tvOS and watchOS) when these targets don't use dSYM files and the debu

Fix a double debug info size counting in top level stats for "statistics dump".

This mainly affects Darwin targets (macOS, iOS, tvOS and watchOS) when these targets don't use dSYM files and the debug info was in the .o files. All modules, including the .o files that are loaded by the debug maps, were in the global module list. This was great because it allows us to see each .o file and how much it contributes. There were virtual functions on the SymbolFile class to fetch the symtab/debug info parse and index times, and also the total debug info size. So the main executable would add all of the .o file's stats together and report them as its own data. Then the "totalDebugInfoSize" and many other "totalXXX" top level totals were all being added together. This stems from the fact that my original patch only emitted the modules for a target at the start of the patch, but as comments from the reviews came in, we switched to emitting all of the modules from the global module list.

So this patch fixes it so when we have a SymbolFileDWARFDebugMap that loads .o files, the main executable will have no debug info size or symtab/debug info parse/index times, but each .o file will have its own data as a separate module. Also, to be able to tell when/if we have a dSYM file I have added a "symbolFilePath" if the SymbolFile for the main modules path doesn't match that of the main executable. We also include a "symbolFileModuleIdentifiers" key in each module if the module does have multiple lldb_private::Module objects that contain debug info so that you can track down the information for a module and add up the contributions of all of the .o files.

Tests were added that are labeled with @skipUnlessDarwin and @no_debug_info_test that test all of this functionality so it doesn't regress.

For a module with a dSYM file, we can see the "symbolFilePath" is included:
```
"modules": [
{
"debugInfoByteSize": 1070,
"debugInfoIndexLoadedFromCache": false,
"debugInfoIndexSavedToCache": false,
"debugInfoIndexTime": 0,
"debugInfoParseTime": 0,
"identifier": 4873280600,
"path": "/Users/gclayton/Documents/src/lldb/main/Debug/lldb-test-build.noindex/commands/statistics/basic/TestStats.test_dsym_binary_has_symfile_in_stats/a.out",
"symbolFilePath": "/Users/gclayton/Documents/src/lldb/main/Debug/lldb-test-build.noindex/commands/statistics/basic/TestStats.test_dsym_binary_has_symfile_in_stats/a.out.dSYM/Contents/Resources/DWARF/a.out",
"symbolTableIndexTime": 7.9999999999999996e-06,
"symbolTableLoadedFromCache": false,
"symbolTableParseTime": 7.8999999999999996e-05,
"symbolTableSavedToCache": false,
"triple": "arm64-apple-macosx12.0.0",
"uuid": "E1F7D85B-3A42-321E-BF0D-29B103F5F2E3"
},
```
And for the DWARF in .o file case we can see the "symbolFileModuleIdentifiers" in the executable's module stats:
```
"modules": [
{
"debugInfoByteSize": 0,
"debugInfoIndexLoadedFromCache": false,
"debugInfoIndexSavedToCache": false,
"debugInfoIndexTime": 0,
"debugInfoParseTime": 0,
"identifier": 4603526968,
"path": "/Users/gclayton/Documents/src/lldb/main/Debug/lldb-test-build.noindex/commands/statistics/basic/TestStats.test_no_dsym_binary_has_symfile_identifiers_in_stats/a.out",
"symbolFileModuleIdentifiers": [
4604429832
],
"symbolTableIndexTime": 7.9999999999999996e-06,
"symbolTableLoadedFromCache": false,
"symbolTableParseTime": 0.000112,
"symbolTableSavedToCache": false,
"triple": "arm64-apple-macosx12.0.0",
"uuid": "57008BF5-A726-3DE9-B1BF-3A9AD3EE8569"
},
```
And the .o file for 4604429832 looks like:
```
{
"debugInfoByteSize": 1028,
"debugInfoIndexLoadedFromCache": false,
"debugInfoIndexSavedToCache": false,
"debugInfoIndexTime": 0,
"debugInfoParseTime": 6.0999999999999999e-05,
"identifier": 4604429832,
"path": "/Users/gclayton/Documents/src/lldb/main/Debug/lldb-test-build.noindex/commands/statistics/basic/TestStats.test_no_dsym_binary_has_symfile_identifiers_in_stats/main.o",
"symbolTableIndexTime": 0,
"symbolTableLoadedFromCache": false,
"symbolTableParseTime": 0,
"symbolTableSavedToCache": false,
"triple": "arm64-apple-macosx"
}
```

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

show more ...

[lldb] Make StatsDuration thread-safe

std::chrono::duration types are not thread-safe, and they cannot be
concurrently updated from multiple threads. Currently, we were doing
such a thing (only) in

[lldb] Make StatsDuration thread-safe

std::chrono::duration types are not thread-safe, and they cannot be
concurrently updated from multiple threads. Currently, we were doing
such a thing (only) in the DWARF indexing code
(DWARFUnit::ExtractDIEsRWLocked), but I think it can easily happen that
someone else tries to update another statistic like this without
bothering to check for thread safety.

This patch changes the StatsDuration type from a simple typedef into a
class in its own right. The class stores the duration internally as
std::atomic<uint64_t> (so it can be updated atomically), but presents it
to its users as the usual chrono type (duration<float>).

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

show more ...

Remove ConstString from Language, LanguageRuntime, SystemRuntime and SymbolFile plugin names

Add new key/value pairs to the module statistics for "statistics dump".

The new key/value pairs that are added to each module's stats are:
"debugInfoByteSize": The size in bytes of debug info for ea

Add new key/value pairs to the module statistics for "statistics dump".

The new key/value pairs that are added to each module's stats are:
"debugInfoByteSize": The size in bytes of debug info for each module.
"debugInfoIndexTime": The time in seconds that it took to index the debug info.
"debugInfoParseTime": The time in seconds that debug info had to be parsed.

At the top level we add up all of the debug info size, parse time and index time with the following keys:
"totalDebugInfoByteSize": The size in bytes of all debug info in all modules.
"totalDebugInfoIndexTime": The time in seconds that it took to index all debug info if it was indexed for all modules.
"totalDebugInfoParseTime": The time in seconds that debug info was parsed for all modules.

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

show more ...

[lldb] Return StringRef from PluginInterface::GetPluginName

There is no reason why this function should be returning a ConstString.

While modifying these files, I also fixed several instances where

[lldb] Return StringRef from PluginInterface::GetPluginName

There is no reason why this function should be returning a ConstString.

While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.

I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.

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

show more ...

[lldb] Remove PluginInterface::GetPluginVersion

In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.

Differential Revision: https://

[lldb] Remove PluginInterface::GetPluginVersion

In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.

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

show more ...

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,mo

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,

https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html

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

show more ...

[lldb] Use C++11 default member initializers

This converts a default constructor's member initializers into C++11
default member initializers. This patch was automatically generated with
clang-tidy

[lldb] Use C++11 default member initializers

This converts a default constructor's member initializers into C++11
default member initializers. This patch was automatically generated with
clang-tidy and the modernize-use-default-member-init check.

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix

This is a mass-refactoring patch and this commit will be added to
.git-blame-ignore-revs.

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

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

ParseXcodeSDK: Register both the CU module and the SymbolFile module.

For Swift LLDB (but potentially also for module support in Clang-land)
we need a way to accumulate the path remappings produced

ParseXcodeSDK: Register both the CU module and the SymbolFile module.

For Swift LLDB (but potentially also for module support in Clang-land)
we need a way to accumulate the path remappings produced by
Module::RegisterXcodeSDK(). In order to make this work for
SymbolFileDebugMaps, registering the search path remapping with both
modules is necessary.

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

<rdar://problem/62750529>

show more ...

Add an explicit API to read the Xcode SDK DWARF attribute from compile units

When debugging from a SymbolMap the creation of CompileUnits for the
individual object files is so lazy that RegisterXcod

Add an explicit API to read the Xcode SDK DWARF attribute from compile units

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

show more ...

[lldb][NFC] Make all CompilerDeclContext parameters references instead of pointers

Summary:
All of our lookup APIs either use `CompilerDeclContext &` or `CompilerDeclContext *` semi-randomly it seem

[lldb][NFC] Make all CompilerDeclContext parameters references instead of pointers

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

show more ...

[lldb] Update header guards to be consistent and compliant with LLVM (NFC)

LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pa

[lldb] Update header guards to be consistent and compliant with LLVM (NFC)

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

show more ...

[DWARF] Handle call sites with indirect call targets

Split CallEdge into DirectCallEdge and IndirectCallEdge. Teach
DWARFExpression how to evaluate entry values in cases where the current
activation

[DWARF] Handle call sites with indirect call targets

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

show more ...

Add RTTI support to the SymbolFile class hierarchy

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

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] Fix a bunch of -Wdocumentation warnings

Modernize the rest of the Find.* API (NFC)

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 p

Modernize the rest of the Find.* API (NFC)

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

show more ...

Remove size_t return parameter from FindTypes

In r368345 I accidentally introduced a regression that would
over-report the number of matches found by FindTypes if the
DeclContext Filter was hit.

Th

Remove size_t return parameter from FindTypes

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

show more ...

Remove unused "append" parameter from FindTypes API

I noticed that SymbolFileDWARFDebugMap::FindTypes was implementing it
incorrectly (passing append=false in a for-loop to recursive calls to
FindTy

Remove unused "append" parameter from FindTypes API

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

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

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

SymbolVendor: Move compile unit handling into the SymbolFile class

Summary:
SymbolFile classes are responsible for creating CompileUnit instances
and they already need to have a notion of the id<->C

SymbolVendor: Move compile unit handling into the SymbolFile class

Summary:
SymbolFile classes are responsible for creating CompileUnit instances
and they already need to have a notion of the id<->CompileUnit mapping
(because of APIs like ParseCompileUnitAtIndex). However, the
SymbolVendor has remained as the thing responsible for caching created
units (which the SymbolFiles were calling via convoluted constructs like
"m_obj_file->GetModule()->GetSymbolVendor()->SetCompileUnitAtIndex(...)").

This patch moves the responsibility of caching the units into the
SymbolFile class. It does this by moving the implementation of
SymbolVendor::{GetNumCompileUnits,GetCompileUnitAtIndex} into the
equivalent SymbolFile functions. The SymbolVendor functions become just
a passthrough much like the rest of SymbolVendor.

The original implementations of SymbolFile::GetNumCompileUnits is moved
to "CalculateNumCompileUnits", and are made protected, as the "Get"
function is the external api of the class.
SymbolFile::ParseCompileUnitAtIndex is made protected for the same
reason.

This is the first step in removing the SymbolVendor indirection, as
proposed in
<http://lists.llvm.org/pipermail/lldb-dev/2019-June/015071.html>. After
removing all interesting logic from the SymbolVendor class, I'll proceed
with removing the indirection itself.

Reviewers: clayborg, jingham, JDevlieghere

Subscribers: jdoerfert, lldb-commits

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

llvm-svn: 366791

show more ...

Fix -Wmismatched-tags introduced in r363910

That commit changed DIERef from a struct to a class, but did not update
the forward-declarations. This fixes one forward-declaration, and
removes other (u

Fix -Wmismatched-tags introduced in r363910

That commit changed DIERef from a struct to a class, but did not update
the forward-declarations. This fixes one forward-declaration, and
removes other (unused) decls.

llvm-svn: 363915

show more ...