In r368879 I made an attempt to guess the path style from the files in
the line table. After some consideration I now think this is a poor
idea. This patch undoes that behavior and instead adds an optional
argument to specify the path style. This allows us to make that decision
elsewhere where we have more information. In case of LLDB based on the
Unit.
llvm-svn: 369072
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368933
After switching over LLDB's line table parser to libDebugInfo, we
noticed two regressions on the Windows bot. The problem is that when
obtaining a file from the line table prologue, we append paths without
specifying a path style. This leads to incorrect results on Windows for
debug info containing Posix paths:
0x0000000000201000: /tmp\b.c, is_start_of_statement = TRUE
This patch is an attempt to fix that by guessing the path style whenever
possible.
Differential revision: https://reviews.llvm.org/D66227
llvm-svn: 368879
My previous change didn't fix the Windows bot. This patch is an attempt
to make guessing the path style more robust by first looking at the
compile dir and falling back to the actual file if that's unsuccessful.
llvm-svn: 368772
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
When looking up a type by name, also scan through any referenced Clang
modules regardsless of whether a type with this name has been
found. This is NFCish (= a potential performance regression) for Clang
projects, but necessary in mixed Swift and Objective-C projects (and
tested in swift-lldb).
This only affects projects compiled with -gmodules that were not run
through dsymutil.
llvm-svn: 368345
After the recent refactorings the SymbolVendor passthrough no longer
serve any purpose. This patch removes those methods, and updates all
callsites to go to the symbol file directly -- in most cases that just
means calling GetSymbolFile()->foo() instead of
GetSymbolVendor()->foo().
llvm-svn: 368001
Summary:
This is the next step in avoiding funneling all SymbolFile calls through
the SymbolVendor. Right now, it is just a convenience function, but it
allows us to update all calls to SymbolVendor functions to access the
SymbolFile directly. Once all call sites have been updated, we can
remove the GetSymbolVendor member function.
This patch just updates the calls to GetSymbolVendor, which were calling
it just so they could fetch the underlying symbol file. Other calls will
be done in follow-ups.
Reviewers: JDevlieghere, clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D65435
llvm-svn: 367664
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
Summary:
This commit achieves the following:
- Functions used to return a `TypeSystem *` return an
`llvm::Expected<TypeSystem *>` now. This means that the result of a call
is always checked, forcing clients to move more carefully.
- `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a
non-null pointer to a TypeSystem.
Reviewers: JDevlieghere, davide, compnerd
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D65122
llvm-svn: 367360
As of svn rL367298, SymbolFileDWARF locks the module in many cases where
it needs to parse some aspect of the DWARF symbol file.
SymbolFileDWARF::ParseLineTable needs to lock the module because
SymbolVendor::ParseLineTable no longer locks it.
llvm-svn: 367358
Summary:
The last bit of functionality in SymbolVendor passthrough functions is
the locking the module mutex. While it may be nice doing the locking in
a central place, we weren't really succesful in doing that right now,
because some SymbolFile function could still be called without going
through the SymbolVendor. This meant in SymbolFileDWARF (the only
battle-tested symbol file implementation) roughly a half of the
functions was taking additional locks and another half was asserting
that the lock is already held. By making the SymbolFile responsible for
locking, we can at least make the situation in SymbolFileDWARF more
consistent.
Reviewers: clayborg, JDevlieghere, jingham, jdoerfert
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D65329
llvm-svn: 367298
Summary:
This is a bit more explicit, and makes it possible to build LLDB without
varying the -I lines per-directory.
(The latter is useful because many build systems only allow this to be
configured per-library, and LLDB is insufficiently layered to be split into
multiple libraries on stricter build systems).
(My comment on D65185 has some more context)
Reviewers: JDevlieghere, labath, chandlerc, jdoerfert
Reviewed By: labath
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65397
Patch by Sam McCall!
llvm-svn: 367241
Right now our Properties.inc only generates the initializer for the
options list but not the array declaration boilerplate around it. As the
array definition is identical for all arrays, we might as well also let
the Properties.inc generate it alongside the initializers.
Unfortunately we cannot do the same for enums, as there's this magic
ePropertyExperimental, which needs to come at the end to be interpreted
correctly. Hopefully we can get rid of this in the future and do the
same for the property enums.
Differential revision: https://reviews.llvm.org/D65353
llvm-svn: 367238
Delete the abstract GetOffset function, which is only defined for
rnglists entries. Instead fix up entries which refer to the range list
classes so that one can statically know that he is dealing with the
rnglists section and call the function that way.
llvm-svn: 367106
Property definitions are currently defined in a PropertyDefinition array
and have a corresponding enum to index in this array. Unfortunately this
is quite error prone. Indeed, just today we found an incorrect merge
where a discrepancy between the order of the enum values and their
definition caused the test suite to fail spectacularly.
Tablegen can streamline the process of generating the property
definition table while at the same time guaranteeing that the enums stay
in sync. That's exactly what this patch does. It adds a new tablegen
file for the properties, building on top of the infrastructure that
Raphael added recently for the command options. It also introduces two
new tablegen backends: one for the property definitions and one for
their corresponding enums.
It might be worth mentioning that I generated most of the tablegen
definitions from the existing property definitions, by adding a dump
method to the struct. This seems both more efficient and less error
prone that copying everything over by hand. Only Enum properties needed
manual fixup for the EnumValues and DefaultEnumValue fields.
Differential revision: https://reviews.llvm.org/D65185
llvm-svn: 367058
Summary:
Similarly to the compile unit lists, the list of types can also be
managed by the symbol file itself.
Since the only purpose of this list seems to be to maintain an owning
reference to all the types a symbol file has created (items are only
ever added to the list, never retrieved), I remove the passthrough
functions in SymbolVendor and Module. I also tighten the interface of
the function (return a reference instead of a pointer, make it protected
instead of public).
Reviewers: clayborg, JDevlieghere, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D65135
llvm-svn: 366994
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
Instead of having to write FileSpecList::Append(FileSpec(args)) you can
now call FileSpecList::EmplaceBack(args), similar to
std::vector<>::emplace_back.
llvm-svn: 366489
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
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
Summary:
A user_id_t carries the same information as a DIERef, but it takes up
less space.
Furthermore, DIERef::operator<'s implementation is very
questionable, as it does not take the cu_offset and section fields into
account. Using just the die offset was correct in the days when all
debug info lived in a single section, but since we started supporting
DWO debug info, this was no longer true. The comparison operator could
be fixed, but it seems like using the user_id_t for these purposes is a
better idea overall.
I think this did not cause any bugs, because the only place the
comparison operator was used is in m_function_scope_qualified_name_map,
and this one is local to a dwo file, but I am not 100% sure of that.
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D63322
llvm-svn: 363528
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
In a dwo/debug_types world, the die offset is not enough to uniquely
idendify a debug info entry. Pass the the entire DIERef object instead.
This is technically NFC, because only AppleIndex implemented this
method (and there, the die offset *is* enough for unique
identification). However, this makes the code simpler, and simplifies
some of the follow-up patches.
llvm-svn: 363373
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
Summary:
This patch creates a cache of file lists in line tables referenced by
type units. This cache is used to avoid parsing a line table twice
(since a file list will generally be shared by many type units).
It also sets things up in a way that parsing of DW_AT_decl_file
attributes will keep working even when we stop creating lldb compile
units for dwarf type units, but it stops short of actually doing that.
This means that the request for files now go directly to SymbolFileDWARF
instead of being routed there indirectly via the
lldb_private::CompileUnit class.
As a result of this, a number of occurences of SymbolContext variables
in DWARFASTParserClang have become unused, so I remove them.
This patch reduces the number of times a file list is being parsed, but
the situation is still suboptimal, as the parsed list is being copied
multiple times. This will be fixed when we stop creating CompileUnits
for DWARF type units.
Reviewers: clayborg, aprantl, JDevlieghere
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D62894
llvm-svn: 363143
This reverts commit 58afc1bdebf9fa8b178d6c9d89af94c5cc091760.
This commit caused the test suite on macOS to fail many tests. It
appears that setting breakpoints is the issue. One example that fails
is the lit test Breakpoint/case-sensitive.test.
llvm-svn: 362862
Summary:
The DWARFCompileUnit is set as the "user data" of the lldb compile unit
directly in the constructor (see ParseCompileUnit).
This means that instead of going through unit indexes, we can just fetch
the DWARF unit directly from there.
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D62943
llvm-svn: 362783
Summary:
This code is modifying a support file list after it has been created.
This makes it hard to share the file list between type units and
compile units in DWARF. It's not a total showstopper, but supporting
this while also sharing the lists would make things more complicated.
Given that this was added to support a project which never fully
materialised, and that even back then there were some concerns about the
correctness of this approach (according to D11003#200772 the compile
unit name is not guaranteed to be the first one in the support file
list), I think we should just delete this workaround.
Reviewers: clayborg, tberghammer, dsrbecky
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D62517
llvm-svn: 361948
Summary:
debug_ranges got renamed to debug_rnglists in DWARF 5. Prior to this
patch lldb was just picking the first section it could find in the file,
and using that for all address ranges lookups. This is not correct in
case the file contains a mixture of compile units with various standard
versions (not a completely unlikely scenario).
In this patch I make lldb support reading from both sections
simulaneously, and decide the correct section to use based on the
version number of the compile unit. SymbolFileDWARF::DebugRanges is
split into GetDebugRanges and GetDebugRngLists (the first one is renamed
mainly so we can catch all incorrect usages).
I tried to structure the code similarly to how llvm handles this logic
(hence DWARFUnit::FindRnglistFromOffset/Index), but the implementations
are still relatively far from each other.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D62302
llvm-svn: 361938
Like many of our DWARF classes, the DWARFExpression can be initialized
in several ways. One such way was through a constructor that takes just
the compile unit. This constructor is used to initialize both empty
DWARFExpressions, and DWARFExpression that will be populated later.
To make the distinction more clear, I changed the constructor to a
default constructor and updated its call sites. Where the
DWARFExpression was being populated later, I replaced that with a call
to the copy assignment constructor.
Differential revision: https://reviews.llvm.org/D62425
llvm-svn: 361849
These variables were useful when looking up the compile unit index
required a binary search. Now that we can look up a compile unit index
in constant time, they are no longer needed.
llvm-svn: 361754
The fix form sizes use to have two arrays: one for 4 byte addresses and in for 8 byte addresses. The table had an issue where DW_FORM_flag_present wasn't being represented as a fixed size form because its actual size _is_ zero and zero was used to indicate the form isn't fixed in size. Any code that needed to quickly access the DWARF had to get a FixedFormSizes instance using the address byte size.
This fix cleans things up by adding a DWARFFormValue::GetFixedSize() both as a static method and as a member function on DWARFFormValue. It correctly can indicate if a form size is zero. This cleanup is a precursor to a follow up patch where I hope to speed up DWARF parsing.
I verified performance doesn't regress by loading hundreds of DWARF files and setting a breakpoint by file and line and by name in files that do not have DWARF indexes. Performance remained consistent between the two approaches.
Differential Revision: https://reviews.llvm.org/D62416
llvm-svn: 361675
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
Summary:
This patch introduces the DWARFTypeUnit class, and teaches lldb to parse
type units out of both the debug_types section (DWARF v4), and from the
regular debug_info section (DWARF v5).
The most important piece of functionality - resolving DW_AT_signatures
to connect type forward declarations to their definitions - is not
implemented here, but even without that, a lot of functionality becomes
available. I've added tests for the commands that start to work after
this patch.
The changes in this patch were greatly inspired by D61505, which in turn took
over changes from D32167.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mgorny, jankratochvil, lldb-commits
Differential Revision: https://reviews.llvm.org/D62008
llvm-svn: 361360
In D61502#1503247 @clayborg suggested that SymbolFileDWARF *dwarf2Data is
really redundant in all the calls with also having DWARFUnit *cu. So remove it.
One `SymbolFileDWARF *` nullptr check
(DWARFDebugInfoEntry::GetDIENamesAndRanges) could be removed, other two nullptr
checks (DWARFDebugInfoEntry::GetName and DWARFDebugInfoEntry::AppendTypeName)
need to stay in place (now for `DWARFUnit *`).
Differential Revision: https://reviews.llvm.org/D62011
llvm-svn: 361277
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
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
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
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
Summary:
Instead of using the offset of the contained compile unit, we use it's
ID. The goal of this change is two-fold:
- free up space in the user_id_t representation to enable storing the
debug-info-carrying section (debug_types/debug_info) without
decreasing the amount of debug info we can address (as would be the
case with D61503).
- be a step towards supporting DWO files containing more than one unit
(important for debug_types+dwo, but can also happen with regular
dwo+lto). For this part to fully work we'd still need to add a way to
lookup the SymbolFileDWO without going through GetCompileUnitAtIndex,
but making sure things don't accidentally work because the SymbolFile
ID is the same as compile unit offset is a step towards that.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mehdi_amini, dexonsmith, tberghammer, jankratochvil, lldb-commits
Differential Revision: https://reviews.llvm.org/D61783
llvm-svn: 360565
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
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
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
Summary:
This check seems unnecessary as we already assert the same condition above and also access `sc.comp_unit`
before this check.
Reviewers: aprantl
Reviewed By: aprantl
Subscribers: jdoerfert, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61394
llvm-svn: 359813
Before a Debugger gets a Target, target settings are routed to a global set
of settings. Even without this, some part of the LLDB which exist independently
of the Debugger object (the Module cache, the Symbol vendors, ...) access
directly the global default store for those settings.
Of course, if you modify one of those global settings while they are being read,
bad things happen. We see this quite a bit with FileSpecList settings. In
particular, we see many cases where one debug session changes
target.exec-search-paths while another session starts up and it crashes when
one of those accesses invalid FileSpecs.
This patch addresses the specific FileSpecList issue by adding locking to
OptionValueFileSpecList and never returning by reference.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60468
llvm-svn: 359028
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
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
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
LLVM's DWARF parsing library has a class called DWARFContext which holds
all of the various DWARF data sections and lots of other information.
LLDB's on the other hand stores all of this directly in SymbolFileDWARF
/ SymbolFileDWARFDwo and passes this interface around through the
parsing library. Obviously this is incompatible with a world where the
low level interface does not depend on the high level interface, so we
need to move towards a model similar to LLVM's - i.e. all of the context
needed for low level parsing should be in a single class, and that class
gets passed around.
This patch is a small incremental step towards achieving this. The
interface and internals deviate from LLVM's for technical reasons, but
the high level idea is the same. The goal is, eventually, to remove all
occurrences of SymbolFileDWARF from the low level parsing code.
For now I've chosen a very simple section - the .debug_aranges section
to move into DWARFContext while leaving everything else unchanged. In
the short term this is a bit confusing because now the information you
need might come from either of 2 different locations. But it's a huge
refactor to do this all at once and runs a much higher risk of breaking
things. So I think it would be wise to do this in very small pieces.
TL;DR - No functional change
Differential Revision: https://reviews.llvm.org/D59562
llvm-svn: 356612
All of this is code that is unreferenced. Removing as much of
this as possible makes it more easy to determine what functionality
is missing and/or shared between LLVM and LLDB's DWARF interfaces.
llvm-svn: 356509
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
The goal here is to improve our error handling and error recovery while
parsing DWARF, while at the same time getting us closer to being able to
merge LLDB's DWARF parser with LLVM's. To this end, I've udpated several
of the low-level parsing functions in LLDB to return llvm::Error and
llvm::Expected.
For now, this only updates LLDB parsing functions and not LLVM. In some
ways, this actually gets us *farther* from parity with the two
interfaces, because prior to this patch, at least the parsing interfaces
were the same (i.e. they all just returned bools, and now with this
patch they're diverging). But, I chose to do this for two primary
reasons.
LLDB has error logging code engrained deep within some of its parsing
functions. We don't want to lose this logging information, but obviously
LLVM has no logging mechanism at all. So if we're to merge the
interfaces, we have to find a way to still allow LLDB to properly report
parsing errors while not having the reporting code be inside of LLVM.
LLDB (and indeed, LLVM) overload the meaning of the false return value
from all of these extraction functions to mean both "We reached the null
entry at the end of a list of items, therefore everything was
successful" as well as "something bad and unrecoverable happened during
parsing". So you would have a lot code that would do something like:
while (foo.extract(...)) {
...
}
But when the loop stops, why did it stop? Did it stop because it
finished parsing, or because there was an error? Because of this, in
some cases we don't always know whether it is ok to proceed, or how to
proceed, but we were doing it anyway.
In this patch, I solve the second problem by introducing an
enumeration called DWARFEnumState which has two values MoreItems and
Complete. Both of these indicate success, but the latter indicates
that we reached the null entry. Then, I return this value instead of
bool, and convey parsing failure separately.
To solve the first problem (and convey parsing failure) these
functions now return either llvm::Error or llvm::Expected<DWARFEnumState>.
Having this extra bit of information allows us to properly convey all 3 of
"error, bail out", "success, call this function again", and "success,
don't call this function again".
In subsequent patches I plan to extend this pattern to the rest of the
parsing interfaces, which will ultimately get all of the log statements
and error reporting out of the low level parsing code and into the high
level parsing code (e.g. SymbolFileDWARF, DWARFASTParserClang, etc).
Eventually, these same changes will have to be backported to LLVM's
DWARF parser, but diverging in the short term is the easiest way to
converge in the long term.
Differential Revision: https://reviews.llvm.org/D59370
llvm-svn: 356190
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
This is a very thin wrapper over a std::vector<DWARFDIE> and does
not seem to provide any real value over just using a container
directly.
Differential Revision: https://reviews.llvm.org/D59165
llvm-svn: 355974
Summary:
This patch marks the inline namespaces from DWARF as inline and also ensures that looking
up declarations now follows the lookup rules for inline namespaces.
Reviewers: aprantl, shafik, serge-sans-paille
Reviewed By: aprantl
Subscribers: eraman, jdoerfert, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D59198
llvm-svn: 355897
My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.
ConstString has exactly one const char * data member, so passing a
ConstString by reference is not any more efficient than copying it by
value. In both cases a single pointer is passed. But passing it by
value makes it harder to accidentally return the address of a local
object.
(This fixes rdar://problem/48640859 for the Apple folks)
Differential Revision: https://reviews.llvm.org/D59030
llvm-svn: 355553
This was reverted because it breaks the GreenDragon bot, but
the reason for the breakage is lost, so I'm resubmitting this
now so we can find out what the problem is.
llvm-svn: 355528
Given that we have a target named Symbols, one wonders why a
file named Symbols.cpp is not in this target. To be clear,
the functions exposed from this file are really focused on
*locating* a symbol file on a given host, which is where the
ambiguity comes in. However, it makes more sense conceptually
to be in the Symbols target. While some of the specific places
to search for symbol files might change depending on the Host,
this is not inherently true in the same way that, for example,
"accessing the file system" or "starting threads" is
fundamentally dependent on the Host.
PDBs, for example, recently became a reality on non-Windows platforms,
and it's theoretically possible that DSYMs could become a thing on non
MacOSX platforms (maybe in a remote debugging scenario). Other types of
symbol files, such as DWO, DWP, etc have never been tied to any Host
platform anyway.
After this patch, there is only one remaining dependency from
Host to Target.
Differential Revision: https://reviews.llvm.org/D58730
llvm-svn: 355032
Host had a function to get the UnixSignals instance corresponding
to the current host architecture. This means that Host had to
include a file from Target. To break this dependency, just make
this a static function directly in UnixSignals. We already have
the function UnixSignals::Create(ArchSpec) anyway, so we just
need to have UnixSignals::CreateForHost() which determines which
value to pass for the ArchSpec.
The goal here is to eventually break the Host->Target->Host
circular dependency.
Differential Revision: https://reviews.llvm.org/D57780
llvm-svn: 354168
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
The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.
In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.
I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.
llvm-svn: 353912
Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared to ::reset(new), it also performs a single
heap allocation for the object and control block.
Differential revision: https://reviews.llvm.org/D57990
llvm-svn: 353764
This is a continuation of my quest to make the size 0 a supported value.
This reapplies r352394 with additional PDB parser fixes prepared by
Pavel Labath!
Differential Revision: https://reviews.llvm.org/D57273
llvm-svn: 352521
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
Summary:
If we opened a file which was produced on system with different path
syntax, we would parse the paths from the debug info incorrectly.
The reason for that is that we would parse the paths as they were
native. For example this meant that on linux we would treat the entire
windows path as a single file name with no directory component, and then
we would concatenate that with the single directory component from the
DW_AT_comp_dir attribute. When parsing posix paths on windows, we would
at least get the directory separators right, but we still would treat
the posix paths as relative, and concatenate them where we shouldn't.
This patch attempts to remedy this by guessing the path syntax used in
each compile unit. (Unfortunately, there is no info in DWARF which would
give the definitive path style used by the produces, so guessing is all
we can do.) Currently, this guessing is based on the DW_AT_comp_dir
attribute of the compile unit, but this can be refined later if needed
(for example, the DW_AT_name of the compile unit may also contain some
useful info). This style is then used when parsing the line table of
that compile unit.
This patch is sufficient to make the line tables come out right, and
enable breakpoint setting by file name work correctly. Setting a
breakpoint by full path still has some kinks (specifically, using a
windows-style full path will not work on linux because the path will be
parsed as a linux path), but this will require larger changes in how
breakpoint setting works.
Reviewers: clayborg, zturner, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D56543
llvm-svn: 351328
This parameter was only ever used with the Module set, and
since a SymbolFile is tied to a module, the parameter turns
out to be entirely unnecessary. Furthermore, it doesn't make
a lot of sense to ask a caller to ask SymbolFile which is tied
to Module X to find types for Module Y, but that possibility
was open with the previous interface. By removing this
parameter from the API, it makes it harder to use incorrectly
as well as easier for an implementor to understand what it
needs to do.
llvm-svn: 351133
Every callsite was passing an empty SymbolContext, so this parameter
had no effect. Inside the DWARF implementation of this function,
however, there was one codepath that checked members of the
SymbolContext. Since no call-sites actually ever used this
functionality, it was essentially dead code, so I've deleted this
code path as well.
llvm-svn: 351132
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
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
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
Summary:
instead of returning the architecture through by-ref argument and a
boolean value indicating success, we can just return the ArchSpec
directly. Since the ArchSpec already has an invalid state, it can be
used to denote the failure without the additional bool.
Reviewers: clayborg, zturner, espindola
Subscribers: emaste, arichardson, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56129
llvm-svn: 350291
This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:
run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD
Differential revision: https://reviews.llvm.org/D55584
llvm-svn: 349215
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
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
This is useful for investigating the clang ast as you reconstruct
it via by parsing debug info. It can also be used to write tests
against.
Differential Revision: https://reviews.llvm.org/D54072
llvm-svn: 346149
This patch removes the logic for resolving paths out of FileSpec and
updates call sites to rely on the FileSystem class instead.
Differential revision: https://reviews.llvm.org/D53915
llvm-svn: 345890
This patch removes the Exists method from FileSpec and updates its uses
with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53845
llvm-svn: 345854
This patch removes the GetByteSize method from FileSpec and updates its
uses with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53788
llvm-svn: 345812
This patch extends the FileSystem class with a bunch of functions that
are currently implemented as methods of the FileSpec class. These
methods will be removed in future commits and replaced by calls to the
file system.
The new functions are operated in terms of the virtual file system which
was recently moved from clang into LLVM so it could be reused in lldb.
Because the VFS is stateful, we turned the FileSystem class into a
singleton.
Differential revision: https://reviews.llvm.org/D53532
llvm-svn: 345783
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
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
With the fix: do not forget to hanlde the DW_RLE_start_end, which seems was
omited/forgotten/removed by mistake.
Original commit message:
The patch implements the support for DW_RLE_base_address and DW_RLE_offset_pair
.debug_rnglists entries
Differential revision: https://reviews.llvm.org/D53140
----
Added : /lldb/trunk/lit/Breakpoint/Inputs/debug_rnglist_offset_pair.yaml
Added : /lldb/trunk/lit/Breakpoint/debug_rnglist_offset_pair.test
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.cpp
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.h
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
llvm-svn: 345251
The patch implements the support for DW_RLE_base_address and DW_RLE_offset_pair
.debug_rnglists entries
Differential revision: https://reviews.llvm.org/D53140
llvm-svn: 345127
This implements the support for .debug_loclists section, which is
DWARF 5 version of .debug_loc.
Currently, clang is able to emit it with the use of D53365.
Differential revision: https://reviews.llvm.org/D53436
llvm-svn: 345016
As discussed with Greg at the dev meeting, we need to ensure we have the
module lock in the SymbolFile. Usually the symbol file is accessed
through the symbol vendor which ensures that the necessary locks are
taken. However, there are a few methods that are accessed by the
expression parser and were lacking the lock.
This patch adds the locking where necessary and everywhere else asserts
that we actually already own the lock.
Differential revision: https://reviews.llvm.org/D52543
llvm-svn: 344945
There are several places that call `FindRanges`,
all of them use `Slide` to adjust the ranges found
by the base address.
All except one, which does the same manually in a loop.
Patch updates it to use `Slide` for consistency.
llvm-svn: 344122
This adds a basic support of the .debug_rnglists section.
Only the DW_RLE_start_length and DW_RLE_end_of_list entries are supported.
Differential revision: https://reviews.llvm.org/D52981
llvm-svn: 344119
This patch teaches lldb to detect when there are missing frames in a
backtrace due to a sequence of tail calls, and to fill in the backtrace
with artificial tail call frames when this happens. This is only done
when the execution history can be determined from the call graph and
from the return PC addresses of calls on the stack. Ambiguous sequences
of tail calls (e.g anything involving tail calls and recursion) are
detected and ignored.
Depends on D49887.
Differential Revision: https://reviews.llvm.org/D50478
llvm-svn: 343900
This is a follow-up to https://reviews.llvm.org/D46362.
When evaluating a complex expression in DWARFExpression::Evaluate,
file addresses must be resolved to load addresses before we can
perform operations such as DW_OP_deref on them.
For this the address goes through three steps
1. Read the file address as stored in the DWARF
2. Link/relocate the file address (when reading from a .dSYM, this is a no-op)
3. Convert the file address to a load address.
D46362 implemented step (3) by resolving the file address using the
Module that the original DWARF came from. In the case of a dSYM that
is correct, but when reading from .o files, we need to look up
relocated/linked addresses, so the right place to look them up is the
current frame's module. This patch fixes that by setting the
expression's Module to point to the linked debugmap object.
A word a bout the unorthodox testcase: The motivating testcase for
this fix is in Swift, but I managed to hand-modify LLVM-IR for a
trivial C program to exhibit the same problem, so we can fix this in
llvm.org.
rdar://problem/44689915
Differential Revision: https://reviews.llvm.org/D52678
llvm-svn: 343612
This patch improves the support of DWARF5.
Particularly the reporting of source code locations.
Differential revision: https://reviews.llvm.org/D51935
llvm-svn: 342153
These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall code layering (although it still does not break any particular
dependency completely).
The XCode project will need to be updated after this change.
Differential Revision: https://reviews.llvm.org/D49740
llvm-svn: 339127
SetFile has an optional style argument which defaulted to the native
style. This patch makes that argument mandatory so clients of the
FileSpec class are forced to think about the correct syntax.
At the same time this introduces a (protected) convenience method to
update the file from within the FileSpec class that keeps the current
style.
These two changes together prevent a potential pitfall where the style
might be forgotten, leading to the path being updated and the style
unintentionally being changed to the host style.
llvm-svn: 334663
With the recent changes in FileSpec to use LLVM's path style, it is
possible to delegate a bunch of common path operations to LLVM's path
helpers. This means we only have to maintain a single implementation and
at the same time can benefit from the efforts made by the rest of the
LLVM community.
This is part one of a set of patches. There was no obvious way to split
this so I just worked from top to bottom.
Differential revision: https://reviews.llvm.org/D48084
llvm-svn: 334615
This also fixes a bug where SymbolFileDWARF was returning the same
function multiple times - this can happen if both mangled and demangled
names match the regex. Other lookup lookup functions had code to handle
this case, but it was forgotten here.
llvm-svn: 334277
Summary:
This patch adds the ability to lookup variables to the DWARF v5 index
class.
During review we discovered an inconsistency between how the existing
two indexes handle looking up qualified names of the variables:
- manual index would return a value if the input string exactly matched
the demangled name of some variable.
- apple index ignored the context and returned any variable with the
same base name.
So, this patch also rectifies that situation:
- it removes all context handling from the index classes. The
GetGlobalVariables functions now just take a base name. For manual
index, this meant we can stop putting demangled names into the
variable index (this matches the behavior for functions).
- context extraction is put into SymbolFileDWARF, so that it is common
to all indexes.
- additional filtering based on the context is also done in
SymbolFileDWARF. This is done via a simple substring search, which is
not ideal, but it matches what we are doing for functions (cf.
Module::LookupInfo::Prune).
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47781
llvm-svn: 334181
Summary:
This patch adds the skeleton for implementing the DWARF v5 name index
class. All of the methods are stubbed out and will be implemented in
subsequent patches. The interesting part of the patch is the addition of
a "ignore-file-indexes" setting to the dwarf plugin which enables a
user to force using manual indexing path in lldb (for example as a
debugging aid). I have also added a test that verifies that file indexes
are used by default.
Reviewers: JDevlieghere, clayborg, jingham
Subscribers: mgorny, mehdi_amini, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47629
llvm-svn: 334088
Now that Apple index determines method-ness straight from the debug
info, we don't need to resolve the functions into SymbolContexts inside
the Index classes. This removes the need for callback arguments and
allows us to pull the common parts out of the two implementations of
these functions back into the SymbolFileDWARF class.
Reviewers: JDevlieghere, clayborg
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47147
llvm-svn: 334004
Summary:
As discussed in https://bugs.llvm.org/show_bug.cgi?id=37317,
FindGlobalVariables does not properly handle the case where
append=false. As this doesn't seem to be used in the tree, this patch
removes the parameter entirely.
Reviewers: clayborg, jingham, labath
Reviewed By: clayborg
Subscribers: aprantl, lldb-commits, kubamracek, JDevlieghere
Differential Revision: https://reviews.llvm.org/D46885
Patch by Tom Tromey <ttromey@mozilla.com>.
llvm-svn: 333639
As suggested by Pavel Labath in D46810 DWARFUnit::GetUnitDIEOnly() returning
a pointer to m_first_die should not permit using methods like GetFirstChild().
Differential revision: https://reviews.llvm.org/D47276
llvm-svn: 333224
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
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
Summary:
Before this patch the two paths were doing very different things
- the apple path searched the .apple_names section, which contained
mangled names, as well as basenames of all functions. It returned any
name it found.
- the non-accelerated path looked in the "full name" index we built
ourselves, which contained mangled as well as demangled names of all
functions (but no basenames). Then however, if it did not find a match
it did an extra search in the basename index, with some special
handling for anonymous namespaces.
This aligns the two paths by changing the non-accelerated path to return
the same results as in the apple-tables one. In pratice, this means we
will search in both the "basename", "method" and "fullname" indexes (in
the manual indexes these are separate indexes. This means the function
will return some slightly inappropriate results (e.g. bar::baz::foo when
one asks for a "full name" foo), but this can be handled by additional
filtering, independently indexing method. I've also stopped inserting
demangled names into the "fullname" index, as that is inconsistent with
the apple path.
Reviewers: clayborg, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D46576
llvm-svn: 331855
In an effort to make the .debug_types patch smaller, breaking out the part that reads the .debug_types from object files into a separate patch
Differential Revision: https://reviews.llvm.org/D46529
llvm-svn: 331777
This fixes a bug where
(lldb) target var g_ptr
would populate the global variables list with exactly one entry
because SymbolFileDWARF::ParseVariables() was invoked with a list of
DIEs pre-filtered by name, such that a subsequent call to
(lldb) fr var --show-globals
would only list that one variable, because CompileUnit::m_variables
was already initialized, fooling CompileUnit::GetVariableList().
CompileUnit::GetVariableList() grabs the *complete* list of variables
via (SymbolFileDWARF, ...)::ParseVariablesForContext and that still
calls CompileUnit::SetVariableList(variables) which acts as the
caching mechanism.
Differential Revision: https://reviews.llvm.org/D46220
llvm-svn: 331230
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
Code commonly checks if the parent DIE is DW_TAG_compile_unit.
But DW_TAG_partial_unit also acts as DW_TAG_compile_unit for DWZ
as DWZ is using DW_TAG_imported_unit only at the top unit level.
Differential revision: https://reviews.llvm.org/D40469
llvm-svn: 331194
Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed.
Differential Revision: https://reviews.llvm.org/D45977
llvm-svn: 331049
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
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
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
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
Summary:
The llvm function is equivalent to this one. Where possible I tried to
replace const char* with llvm::StringRef to avoid extra strlen
computations. In most places, I was able to track the c string back to
the ConstString it was created from.
I also create a test that verifies we are able to lookup names with
unicode characters, as a bug in the llvm compiler (it accidentally used
a different hash function) meant this was not working until recently.
This also removes the unused ExportTable class.
Reviewers: aprantl, davide
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D43596
llvm-svn: 325927
Summary:
LLDB doesn't use this code, the code has no tests, and the code does suspicious
things like hashing pointers to strings instead of the strings themselves.
Subscribers: sanjoy, mgorny, JDevlieghere
Differential Revision: https://reviews.llvm.org/D43202
llvm-svn: 324925
Initialize the default value of SymbolFileDWARF uuid with
the appropriately shifted DW_INVALID_OFFSET constant.
This change fixes the collision in the computation of DIE uid
(inside DIERef::GetUID) and incorrect CompileUnit lookup
(because of the misleading cu_offset value).
Test plan: make check-lldb
Differential revision: https://reviews.llvm.org/D42563
llvm-svn: 323832
This fixes a bug in -gmodules DWARF handling when debugging without a .dSYM bundle
that was particularly noticable when debugging LLVM itself.
Debugging without clang modules and DWO handling should be unaffected by this patch.
<rdar://problem/32436209>
llvm-svn: 321802
Summary:
These two functions were calling each other, while handling different
branches of the if(IsInMemory()). This had a reason at some point in the
past, but right now it's just confusing.
I resolve this by removing the MemoryMapSectionData function and
inlining the !IsInMemory branch into ReadSectionData. There isn't
anything mmap-related in this function anyway, as the decision whether
to mmap is handled at a higher level.
This is a preparatory step to make ObjectFileELF be able to decompress
compressed sections (I want to make sure that all calls reading section
data are routed through a single piece of code).
Reviewers: clayborg
Subscribers: emaste, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D41169
llvm-svn: 320705
DWO/DWP should not be indexed directly.
Instead, the corresponding base file should be used.
This diff adds an assert to DWARFCompileUnit::Index
and adjusts the methods
SymbolFileDWARF::FindCompleteObjCDefinitionTypeForDIE,
SymbolFileDWARF::GetObjCMethodDIEOffsets accordingly.
Differential revision: https://reviews.llvm.org/D39825
llvm-svn: 318554
The rationale here is that ArchSpec is used throughout the codebase,
including in places which should not depend on the rest of the code in
the Core module.
This commit touches many files, but most of it is just renaming of
#include lines. In a couple of cases, I removed the #include ArchSpec
line altogether, as the file was not using it. In one or two places,
this necessitated adding other #includes like lldb-private-defines.h.
llvm-svn: 318048
Previously LLDB required the DWP file
to be located next to the executable file.
This diff uses the helper function
Symbols::LocateExecutableSymbolFile to search for
DWP files in the standard locations for debug symbols.
Test plan:
Build a toy test example:
main.cpp
clang -gsplit-dwarf -g -O0 main.cpp -o main.exe
llvm-dwp -e main.exe -o main.exe.dwp
mkdir -p debug_symbols
mv main.exe.dwp debug_symbols/main.exe.dwp
Run lldb:
lldb
settings set target.debug-file-search-paths ./debug_symbols
file ./main.exe
br set --name f
run
Check that debugging works:
setting breakpoints, printing local variables.
Differential revision: https://reviews.llvm.org/D38568
llvm-svn: 315387
FreeBSD kernel modules are actually relocatable (.o) ELF files and this
previously caused some issues for LLDB. This change addresses these when
using lldb to symbolicate FreeBSD kernel backtraces.
The major problems:
- Relocations were not being applied to the DWARF debug info despite
there being code to do this. Several issues prevented it from working:
- Relocations are computed at the same time as the symbol table, but
in the case of split debug files, symbol table parsing always
redirects to the primary object file, meaning that relocations would
never be applied in the debug file.
- There's actually no guarantee that the symbol table has been parsed
yet when trying to parse debug information.
- When actually applying relocations, it will segfault because the
object files are not mapped with MAP_PRIVATE and PROT_WRITE.
- LLDB returned invalid results when performing ordinary address-to-
symbol resolution. It turned out that the addresses specified in the
section headers were all 0, so LLDB believed all the sections had
overlapping "file addresses" and would sometimes return a symbol from
the wrong section.
Patch by Brian Koropoff
Differential Revision: https://reviews.llvm.org/D38142
llvm-svn: 314672
Summary:
This allows for the stack size to be configured, which isn't
possible with std::thread. Prevents overflowing the stack when
performing complex operations in the task pool on darwin,
where the default pthread stack size is only 512kb.
This also moves TaskPool from Utility to Host.
Reviewers: labath, tberghammer, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D37930
llvm-svn: 313637
When LLDB loads "external" modules it looks at the
presence of DW_AT_GNU_dwo_name.
However, when the already created module
(corresponding to .dwo itself) is being processed,
it will see the presence of DW_AT_GNU_dwo_name
(which contains the name of dwo file) and
will try to call ModuleList::GetSharedModule again.
In some cases (i.e. for empty files) Clang 4.0
generates a *.dwo file which has DW_AT_GNU_dwo_name,
but no DW_AT_comp_dir. In this case the method
ModuleList::GetSharedModule will fail and
the warning will be printed. To workaround this issue,
one can notice that in this case we don't actually need
to try to load the already loaded module (corresponding to .dwo).
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D37295
llvm-svn: 313083
Summary:
The DWP (DWARF package) format is used to pack multiple dwo files
generated by split-dwarf into a single ELF file to make distributing
them easier. It is part of the DWARFv5 spec and can be generated by
dwp or llvm-dwp from a set of dwo files.
Caviats:
* Only the new version of the dwp format is supported (v2 in GNU
numbering schema and v5 in the DWARF spec). The old version (v1) is
already deprecated but binutils 2.24 still generates that one.
* Combining DWP files with module debugging is not yet supported.
Subscribers: emaste, mgorny, aprantl
Differential Revision: https://reviews.llvm.org/D36062
llvm-svn: 311775
It was completly unused and broke the part of the encapsulation that
common code shouldn't depend on specific plugins or language specific
features.
llvm-svn: 311000
Current LLDB (that is without DWZ support) crashes accessing Fedora debug info:
READ of size 8 at 0x60200000ffc8 thread T0
#0 in DWARFDebugInfoEntry::BuildAddressRangeTable(SymbolFileDWARF*, DWARFCompileUnit const*, DWARFDebugAranges*) const tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp:1336
Greg Clayton: We will need a warning to be emitted in
SymbolFileDWARF::CalculateAbilities() stating we won't parse the DWARF due to
"unsupported DW_FORM value of 0x1f20".
Patch has been mostly written by Greg Clayton.
Differential revision: https://reviews.llvm.org/D35622
llvm-svn: 309581
Adrian Prantl