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

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

[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] Delete copy operations on PluginInterface class

This is a polymorphic class, copying it is a bad idea.

This was not a problem because most classes inheriting from it were
deleting their copy

[lldb] Delete copy operations on PluginInterface class

This is a polymorphic class, copying it is a bad idea.

This was not a problem because most classes inheriting from it were
deleting their copy operations themselves. However, this enables us to
delete those explicit deletions, and ensure noone forgets to add them in
the future.

show more ...

[lldb] NFC remove DISALLOW_COPY_AND_ASSIGN

Summary:
This is how I applied my clang-tidy check (see
https://reviews.llvm.org/D80531) in order to remove
`DISALLOW_COPY_AND_ASSIGN` and have deleted cop

[lldb] NFC remove DISALLOW_COPY_AND_ASSIGN

Summary:
This is how I applied my clang-tidy check (see
https://reviews.llvm.org/D80531) in order to remove
`DISALLOW_COPY_AND_ASSIGN` and have deleted copy ctors and deleted
assignment operators instead.

```
lang=bash
grep DISALLOW_COPY_AND_ASSIGN /opt/notnfs/kkleine/llvm/lldb -r -l | sort | uniq > files

for i in $(cat files);
do
clang-tidy \
--checks="-*,modernize-replace-disallow-copy-and-assign-macro" \
--format-style=LLVM \
--header-filter=.* \
--fix \
-fix-errors \
$i;
done
```

Reviewers: espindola, labath, aprantl, teemperor

Reviewed By: labath, aprantl, teemperor

Subscribers: teemperor, aprantl, labath, emaste, sbc100, aheejin, MaskRay, arphaman, usaxena95, lldb-commits

Tags: #lldb

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

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

Add RTTI support to the SymbolFile class hierarchy

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

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

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

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

Deserialize Clang module search path from DWARF

This patch properly extracts the full submodule path as well as its
search paths from DWARF import decls and passes it on to the
ClangModulesDeclVendo

Deserialize Clang module search path from DWARF

This patch properly extracts the full submodule path as well as its
search paths from DWARF import decls and passes it on to the
ClangModulesDeclVendor.

rdar://problem/47970144

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

llvm-svn: 353961

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

[SymbolFile] Rename ParseFunctionBlocks to ParseBlocksRecursive.

This method took a SymbolContext but only actually cared about the
case where the m_function member was set. Furthermore, it was
int

[SymbolFile] Rename ParseFunctionBlocks to ParseBlocksRecursive.

This method took a SymbolContext but only actually cared about the
case where the m_function member was set. Furthermore, it was
intended to be implemented to parse blocks recursively despite not
documenting this in its name. So we change the name to indicate
that it should be recursive, while also limiting the function
parameter to be a Function&. This lets the caller know what is
required to use it, as well as letting new implementers know what
kind of inputs they need to be prepared to handle.

llvm-svn: 351131

show more ...

[SymbolFile] Make ParseCompileUnitXXX accept a CompileUnit&.

Previously all of these functions accepted a SymbolContext&.
While a CompileUnit is one member of a SymbolContext, there
are also many ot

[SymbolFile] Make ParseCompileUnitXXX accept a CompileUnit&.

Previously all of these functions accepted a SymbolContext&.
While a CompileUnit is one member of a SymbolContext, there
are also many others, and by passing such a monolithic parameter
in this way it makes the requirements and assumptions of the
API unclear for both callers as well as implementors.

All these methods need is a CompileUnit. By limiting the
parameter type in this way, we simplify the code as well as
make it self-documenting for both implementers and users.

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

llvm-svn: 350943

show more ...

Change SymbolFile::ParseTypes to ParseTypesForCompileUnit.

The function SymbolFile::ParseTypes previously accepted a SymbolContext.
This makes it extremely difficult to implement faithfully, because

Change SymbolFile::ParseTypes to ParseTypesForCompileUnit.

The function SymbolFile::ParseTypes previously accepted a SymbolContext.
This makes it extremely difficult to implement faithfully, because you
have to account for all possible combinations of members being set in
the SymbolContext. On the other hand, no clients of this function
actually care about implementing this function to this strict of a
standard. AFAICT, there is actually only 1 client in the entire
codebase, and it is the function ParseAllDebugSymbols, which is itself
only called for testing purposes when dumping information. At this
call-site, the only field it sets is the CompileUnit, meaning that an
implementer of a SymbolFile need not worry about any examining or
handling any other fields which might be set.

By restricting this API to accept exactly a CompileUnit& and nothing
more, we can simplify the life of new SymbolFile plugin implementers by
making it clear exactly what the necessary and sufficient set of
functionality they need to implement is, while at the same time removing
some dead code that tried to handle other types of SymbolContext fields
that were never going to be set anyway.

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

llvm-svn: 350889

show more ...

Remove header grouping comments.

This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdate

Remove header grouping comments.

This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.

llvm-svn: 346626

show more ...

Fix (and improve) the support for C99 variable length array types

Clang recently improved its DWARF support for C VLA types. The DWARF
now looks like this:

0x00000051: DW_TAG_variable [4]

Fix (and improve) the support for C99 variable length array types

Clang recently improved its DWARF support for C VLA types. The DWARF
now looks like this:

0x00000051: DW_TAG_variable [4]
DW_AT_location( fbreg -32 )
DW_AT_name( "__vla_expr" )
DW_AT_type( {0x000000d3} ( long unsigned int ) )
DW_AT_artificial( true )
...
0x000000da: DW_TAG_array_type [10] *
DW_AT_type( {0x000000cc} ( int ) )

0x000000df: DW_TAG_subrange_type [11]
DW_AT_type( {0x000000e9} ( __ARRAY_SIZE_TYPE__ ) )
DW_AT_count( {0x00000051} )

Without this patch LLDB will naively interpret the DIE offset 0x51 as
the static size of the array, which is clearly wrong. This patch
extends ValueObject::GetNumChildren to query the dynamic properties of
incomplete array types.

See the testcase for an example:

4 int foo(int a) {
5 int vla[a];
6 for (int i = 0; i < a; ++i)
7 vla[i] = i;
8
-> 9 pause(); // break here
10 return vla[a-1];
11 }

(lldb) fr v vla
(int []) vla = ([0] = 0, [1] = 1, [2] = 2, [3] = 3)
(lldb) quit

rdar://problem/21814005

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

llvm-svn: 346165

show more ...

Don't type-erase the FunctionNameType or TypeClass enums.

This is similar to D53597, but following up with 2 more enums.
After this, all flag enums should be strongly typed all the way
through to th

Don't type-erase the FunctionNameType or TypeClass enums.

This is similar to D53597, but following up with 2 more enums.
After this, all flag enums should be strongly typed all the way
through to the symbol files plugins.

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

llvm-svn: 345314

show more ...

Don't type-erase the SymbolContextItem enumeration.

When we get the `resolve_scope` parameter from the SB API, it's a
`uint32_t`. We then pass it through all of LLDB this way, as a uint32.
This is

Don't type-erase the SymbolContextItem enumeration.

When we get the `resolve_scope` parameter from the SB API, it's a
`uint32_t`. We then pass it through all of LLDB this way, as a uint32.
This is unfortunate, because it means the user of an API never actually
knows what they're dealing with. We can call it something like
`resolve_scope` and have comments saying "this is a value from the
`SymbolContextItem` enumeration, but it makes more sense to just have it
actually *be* the correct type in the actual C++ type system to begin
with. This way the person reading the code just knows what it is.

The reason to use integers instead of enumerations for flags is because
when you do bitwise operations on enumerations they get promoted to
integers, so it makes it tedious to constantly be casting them back
to the enumeration types, so I've introduced a macro to make this
happen magically. By writing LLDB_MARK_AS_BITMASK_ENUM after defining
an enumeration, it will define overloaded operators so that the
returned type will be the original enum. This should address all
the mechanical issues surrounding using rich enum types directly.

This way, we get a better debugger experience, and new users to
the codebase can get more easily acquainted with the codebase because
their IDE features can help them understand what the types mean.

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

llvm-svn: 345313

show more ...

Remove some dead code in FileSpec.

This in turn triggered some fallout where other files had
been transitively picking up includes that they needed from
FileSpec.h, so I've fixed those up as well.

Remove some dead code in FileSpec.

This in turn triggered some fallout where other files had
been transitively picking up includes that they needed from
FileSpec.h, so I've fixed those up as well.

llvm-svn: 296855

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

Read macro info from .debug_macro section and use it for expression evaluation.

Summary:
DWARF 5 proposes a reinvented .debug_macro section. This change follows
that spec.

Currently, only GCC produ

Read macro info from .debug_macro section and use it for expression evaluation.

Summary:
DWARF 5 proposes a reinvented .debug_macro section. This change follows
that spec.

Currently, only GCC produces the .debug_macro section and hence
the added test is annottated with expectedFailureClang.

Reviewers: spyffe, clayborg, tberghammer

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D15437

llvm-svn: 255729

show more ...

Fix Clang-tidy modernize-use-override warnings in some files in source/Plugins; other minor fixes.

Differential Revision: http://reviews.llvm.org/D13840

llvm-svn: 250721