Originally I wanted to remove the RegularExpression class in Utility and
replace it with llvm::Regex. However, during that transition I noticed
that there are several places where need the regular expression string.
So instead I propose to keep the RegularExpression class and make it a
thin wrapper around llvm::Regex.
This patch also removes the workaround for empty regular expressions.
The result is that we are now (more or less) POSIX conformant.
Differential revision: https://reviews.llvm.org/D66174
llvm-svn: 369153
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
Summary:
Ideally CompilerType would have no knowledge of clang or any individual
TypeSystem. Decoupling clang is relatively straightforward.
Differential Revision: https://reviews.llvm.org/D66102
llvm-svn: 368741
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
Summary:
This patch removes the GetSymbolVendor function, and the various
mentions of the SymbolVendor in the Module class. The implementation of
GetSymbolVendor is "inlined" into the GetSymbolFile class which I
created earlier.
After this patch, the SymbolVendor class still exists inside the Module
object, but only as an implementation detail -- a fancy holder for the
SymbolFile. That will be removed in the next patch.
Reviewers: clayborg, JDevlieghere, jingham, jdoerfert
Subscribers: jfb, lldb-commits
Differential Revision: https://reviews.llvm.org/D65864
llvm-svn: 368263
When ld64 links a binary deterministically using the flag ZERO_AR_DATE,
it sets a timestamp of 0 for N_OSO members in the symtab section, rather
than the usual last modified date of the object file. Prior to this
patch, lldb would compare the timestamp from the N_OSO member against
the last modified date of the object file, and skip loading the object
file if there was a mismatch. This patch updates the logic to ignore the
timestamp check if the N_OSO member has timestamp 0.
The original logic was added in https://reviews.llvm.org/rL181631 as a
safety check to avoid problems when debugging if the object file was out
of date. This was prior to the introduction of deterministic build in
ld64. lld still doesn't support deterministic build.
Other code in llvm already relies on and uses the assumption that a
timestamp of 0 means deterministic build. For example, commit
9ccfddc39d adds similar timestamp checking
logic to dsymutil, but special cases timestamp 0. Likewise, commit
0d1bb79a04 adds a long comment describing
deterministic archive, which mostly uses timestamp 0 for determinism.
Patch from Erik Chen <erikchen@chromium.org>!
Differential Revision: https://reviews.llvm.org/D65826
llvm-svn: 368199
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:
The change https://reviews.llvm.org/D55575 modified ClangASTContext::CreateParameterDeclaration to call decl_ctx->addDecl(decl); this caused a regression since the existing code in DWARFASTParserClang::ParseChildParameters is called with the containing DeclContext. So when end up with cases where we are parsing a parameter for a member function and the parameter is added to the CXXRecordDecl as opposed to the CXXMethodDecl. This example is given in the regression test TestBreakpointInMemberFuncWNonPrimitiveParams.py which without this fix in a modules build leads to assert on setting a breakpoint in a member function with non primitive parameters. This scenario would be common when debugging LLDB or clang.
Differential Revision: https://reviews.llvm.org/D65414
llvm-svn: 367726
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:
On the heels of D62934, this patch uses the same approach to introduce
llvm RTTI support to the ObjectFile hierarchy. It also replaces the
existing uses of GetPluginName doing run-time type checks with
llvm::dyn_cast and friends.
This formally introduces new dependencies from some other plugins to
ObjectFile plugins. However, I believe this is fine because:
- these dependencies were already kind of there, and the only reason
we could get away with not modeling them explicitly was because the
code was relying on magically knowing what will GetPluginName() return
for a particular kind of object files.
- the dependencies themselves are logical (it makes sense for
SymbolVendorELF to depend on ObjectFileELF), or at least don't
actively get in the way (the JitLoaderGDB->MachO thing).
- they don't introduce any new dependency loops as ObjectFile plugins
don't depend on any other plugins
Reviewers: xiaobai, JDevlieghere, espindola
Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65450
llvm-svn: 367413
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
Bitwise-or with a non-zero constant will always evaluate to true. Switch to
bitwise-and which will only evalute to true if the specified bit is set in the
other operand.
llvm-svn: 367386
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
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.
So instead of writing:
if (log)
log->Printf("%s\n", str);
You'd write:
LLDB_LOG(log, "%s\n", str);
This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.
find . -type f -name '*.cpp' -exec \
sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +
Differential revision: https://reviews.llvm.org/D65128
llvm-svn: 366936
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
We intend to make PdbAstBuilder abstract and implement
PdbAstBuilderClang along with any other languages that wish to use
PDBs. Thus, change GetOrCreateDeclForUid from returning a clang decl
to a lldb_private::CompilerDecl.
llvm-svn: 366650
Summary:
Add __kernel_rt_sigreturn to the list of trap handlers for Linux (it's
used as such on aarch64 at least), and __restore_rt as well (used on
x86_64).
Skip decrement-and-recompute for trap handlers in
InitializeNonZerothFrame, as signal dispatch may point the child frame's
return address to the start of the return trampoline.
Parse the 'S' flag for signal handlers from eh_frame augmentation, and
propagate it to the unwind plan.
Reviewers: labath, jankratochvil, compnerd, jfb, jasonmolenda
Reviewed By: jasonmolenda
Subscribers: clayborg, MaskRay, wuzish, nemanjai, kbarton, jrtc27, atanasyan, jsji, javed.absar, kristof.beyls, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D63667
llvm-svn: 366580
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:
A common transformation in NativePDB is to go from lldb types to clang
types and vice versa. This function automates one of those steps.
Differential Revision: https://reviews.llvm.org/D64851
llvm-svn: 366345
Summary:
We intend to make PdbAstBuilder abstract and implement
PdbAstBuilderClang along with any other languages that wish to use
PDBs. This is the first step.
Differential Revision: https://reviews.llvm.org/D64852
llvm-svn: 366293
This patch adds two convenience methods named GetAsLLVM to the LLDB
counterparts of the DWARF DataExtractor and the DWARF context. The
DWARFContext, once created, is cached for future usage.
Differential revision: https://reviews.llvm.org/D64535
llvm-svn: 365819
Summary:
Instead of falling back to ObjCLanguageRuntime, we should be falling
back to every loaded language runtime. This makes ValueObject more
language agnostic.
Reviewers: labath, compnerd, JDevlieghere, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D63240
llvm-svn: 364845
Summary:
With the last round of refactors, supporting type units in dwo files
becomes almost trivial. This patch contains a couple of small fixes,
which taken as a whole make type units work in the split dwarf scenario
(both DWARF4 and DWARF5):
- DWARFContext: make sure we actually read the debug_types.dwo section
- DWARFUnit: set string offsets base on all units in the dwo file, not
just the main CU
- ManualDWARFIndex: index all units in the file
- SymbolFileDWARFDwo: Search for the single compile unit in the file, as
we can no longer assume it will be the first one
The last part makes it obvious that there is still some work to be done
here, namely that we do not support dwo files with multiple compile
units. That is something that should be easier after the DIERef
refactors, but it still requires more work.
Tests are added for the type units+split dwarf + dwarf4/5 scenarios, as
well as a test that checks we behave reasonably in the presence of dwo
files with multiple CUs.
Reviewers: clayborg, JDevlieghere, aprantl
Subscribers: arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63643
llvm-svn: 364274
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
That commit changed DIERef from a struct to a class, but did not update
the forward-declarations. This fixes one forward-declaration, and
removes other (unused) decls.
llvm-svn: 363915
Summary:
Instead of accessing the fields directly, use accessor functions to
provide access to the DIERef components. This allows us to decouple the
external interface, from the internal representation. The external
interface can use llvm::Optional and similar goodies, while the data can
still be stored internally in a more compact representation.
I also document the purpose of the existing DIERef fields.
The main motivation for this change is a need to introduce an additional
field to the DIERef class, but I believe the change has its own merit.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63400
llvm-svn: 363910
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
lldb/lit/SymbolFile/DWARF/debug-types-expressions.test fails with msan.
This change fixes the issue by ensuring FileNameEntry::checksum is
always default-initialized.
llvm-svn: 362843
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:
r362103 exposed a bug, where we could read incorrect data if a skeleton
unit contained more than the single unit DIE. Clang emits these kinds of
units with -fsplit-dwarf-inlining (which is also the default).
Changing lldb to handle these DIEs is nontrivial, as we'd have to change
the UID encoding logic to be able to reference these DIEs, and fix up
various places which are assuming that all DIEs come from the separate
compile unit.
However, it turns out this is not necessary, as the DWO unit contains
all the information that the skeleton unit does. So, this patch just
skips parsing the extra DIEs if we have successfully found the DWO file.
This enforces the invariant that the rest of the code is already
operating under.
This patch fixes a couple of existing tests, but I've also included a
simpler test which does not depend on execution of binaries, and would
have helped us in catching this sooner.
Reviewers: clayborg, JDevlieghere, aprantl
Subscribers: probinson, dblaikie, lldb-commits
Differential Revision: https://reviews.llvm.org/D62852
llvm-svn: 362586
Change rL362280 changed CodeView API getRegisterNames() by adding an input
parameter in CPUType. It is called in LLDB and needs to be updated.
Differential Revision: https://reviews.llvm.org/D62772
llvm-svn: 362349
Changes:
- update comments to detail the info can come from .debug_info or .debug_types
- Rename "debug_info_data" to "data" now that we can get data from .debug_info or .debug_types.
- Also call DWARFDebugInfoEntry::GetAbbreviationDeclarationPtr(...) instead of manually grabbing abbreviation.
llvm-svn: 362116
The issue was caused by the error checking code that was added. It was incorrectly adding an extra abbreviation when DWARFEnumState::Complete was received since it would push an extra abbreviation onto the list with the abbreviation code of zero. This cause m_idx_offset in each DWARFAbbreviationDeclarationSet to be set to UINT32_MAX. This valid indicates we must linearly search for attributes, not access them in O(1) time. This caused every DWARFDebugInfoEntry that would try to get its DWARFAbbreviationDeclaration from the CU's DWARFAbbreviationDeclarationSet to always linearly search the abbreviation set for a given abbreviation code. Easy to see why this would cause things to be slow.
This regression was caused by: https://reviews.llvm.org/D59370. I asked to ensure there was no regression is parsing or access speed, but that must not have been done. In my test with 40 DWARF files trying to set a breakpoint by function name and in a header file, I see a 8% speed improvement with this fix.
There was no regression in correctness, just very inefficient access.
Added full unit testing for DWARFAbbreviationDeclarationSet parsing to ensure this doesn't regress.
Differential Revision: https://reviews.llvm.org/D62630
llvm-svn: 362105
When LLDB first started we didn't have our mmap of the DWARF data done correctly and if the backing file would change we would get live changes as the file changed and it would cause problems. We now mmap correctly and do not run into these issues. There was legacy code in DWARFDebugInfoEntry::GetAbbreviationDeclarationPtr(...) that would always extract the abbrev index each time the function was called to verify that DWARF data hadn't changed and a warning was emitted if it did. We no longer need this and the code was removed. The other thing this function did when it parsed the abbrev index was give us the offset of the first attribute bytes by adding the LEB128 size to the offset. This required an extra parameter to DWARFDebugInfoEntry::GetAbbreviationDeclarationPtr(...) which is now removed. I added "lldb::offset_t DWARFDebugInfoEntry::GetFirstAttributeOffset() const" which calculates this when we need it and modified all sites that need the offset to call it.
Now that we aren't decoding and verifying the abbrev index, it speeds up DWARF access by 1% to 2%.
Differential Revision: https://reviews.llvm.org/D62634
llvm-svn: 362103
Summary:
The ParseTypeFromDWARF function consists of a huge switch on the kind of
type being parsed. Each case in this switch starts with parsing the
attributes of the current DIE. A lot of these attributes are specific to
one kind of a type, but a lot of them are common too, leading to code
duplication.
This patch reduces the duplication (and the size of ParseTypeFromDWARF)
by moving the attribute parsing to a separate function. It creates a
struct (ParsedTypeAttributes), which contains a parsed form of all
attributes which are useful for parsing any kind of a type. The parsing
code for a specific type kind can then access the fields which are
relevant for that specific case.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D62477
llvm-svn: 362075
The function Extract() is almost a duplicate of FastExtract() but is not used.
Delete it and rename FastExtract() to Extract().
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D62593
llvm-svn: 362049
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:
The function was not being consistent in how it retrieved the language
of the current compile unit. Sometimes it did so from the lldb CU
object, and sometimes from the DWARF die. This patch unifies the
handling on the latter. The reason for choosing the DWARF method is
because I'd eventually like to stop creating lldb CUs for dwarf type
units (and so this code needs to would need to work without them).
Reviewers: clayborg, JDevlieghere, aprantl
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D62481
llvm-svn: 361939
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:
This patch implements the main feature of type units. When completing a
type, if we encounter a DW_AT_signature attribute, we use it's value to
lookup the complete definition of the type in the relevant type unit.
To enable this lookup, we build up a map of all type units in a symbol
file when parsing the units. Then we consult this map when resolving the
DW_AT_signature attribute.
I include add a couple of tests which exercise the type lookup feature,
including one that ensure we do something reasonable in case we fail to
lookup the type.
A lot of the ideas in this patch have been taken from D32167 and D61505.
Reviewers: clayborg, JDevlieghere, aprantl, alexshap
Subscribers: mgrang, lldb-commits
Differential Revision: https://reviews.llvm.org/D62246
llvm-svn: 361603
Summary:
SymbolFileDWARF used to load debug sections in a thread-safe manner.
When we moved to DWARFContext, we dropped the thread-safe part, because
we thought it was not necessary.
It turns out this was only mostly correct.
The "mostly" part is there because this is a problem only if we use the
manual index, as that is the only source of intra-module paralelism.
Also, this only seems to occur for extremely simple files (like the ones
I've been creating for tests lately), where we've managed to start
indexing before loading the debug_str section. Then, two threads start
to load the section simultaneously and produce wrong results.
On more complex files, something seems to be loading the debug_str section
before we start indexing, as I haven't been able to reproduce this
there, but I have not investigated what it is.
I've tried to come up with a test for this, but I haven't been able to
reproduce the problem reliably. Still, while doing so, I created a way
to generate many compile units on demand. Given that most of our tests
work with only one or two compile units, it seems like this could be
useful anyway.
Reviewers: aprantl, JDevlieghere, clayborg
Subscribers: arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D62316
llvm-svn: 361602
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:
Type units don't describe any code, so they should never be the result
of any address lookup queries.
Previously, we would compute the address ranges for the type units for
via the line tables they reference because the type units looked a lot
like line-tables-only compile units. However, this is not correct, as
the line tables are only referenced from type units so that other
declarations can use the file names contained in them.
In this patch I make the BuildAddressRangeTable function virtual, and
implement it only for compile units.
Testing this was a bit tricky, because the behavior depends on the order
in which we add things to the address range map. This rarely caused a
problem with DWARF v4 type units, as they are always added after all
CUs. It happened more frequently with DWARF v5, as there clang emits the
type units first. However, this is still not something that it is
required to do, so for testing I've created an assembly file where I've
deliberately sandwiched a compile unit between two type units, which
should isolate us from both changes in how the compiler emits the units
and changes in the order we process them.
Reviewers: clayborg, aprantl, JDevlieghere
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D62178
llvm-svn: 361465
In D61502#1503247 @clayborg suggested that DWARFUnit *+dw_offset_t can be now
replaced by DWARFDIE.
It is moved from DWARFDebugInfoEntry to DWARFDIE as noted by @clayborg.
I have also removed return type as (1) it was wrong in one case and (2) no
existing caller used the return type. I also refactored the deep nesting noted
by @JDevlieghere.
Differential Revision: https://reviews.llvm.org/D62211
llvm-svn: 361463
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
Summary:
This patch introduces the DWARFUnitHeader class. Its purpose (and its
structure, to the extent it was possible to make it) is the same as its
LLVM counterpart -- to extract the unit header information before we
actually construct the unit, so that we know which kind of units to
construct. This is needed because as of DWARF5, type units live in the
.debug_info section, which means it's not possible to statically
determine the type of units in a given section.
Reviewers: aprantl, clayborg, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D62073
llvm-svn: 361224
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:
There are several reasons for doing this:
- generally, there's no reason to differentiate between a section being
absent and it being present, but empty
- it matches more closely what llvm DWARF parser is doing (which also
doesn't differentiate the two cases)
- SymbolFileDWARF also doesn't differentiate the two cases, which makes
porting the rest of sections easier
- it fixes a bug in how the return-null-if-empty logic was implemented
(it returned nullptr only the second time we tried to get the
debug_aranges section), which meant that we hit an assert when trying
to parse an empty-but-present section
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: zturner, lldb-commits
Differential Revision: https://reviews.llvm.org/D61942
llvm-svn: 360874
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
The class has been converted to use DWARFUnit, but a number of uses of
the words compile unit remained. This removes all such references
Get/SetCompileUnit becomes Get/SetUnit, and m_cu becomes m_unit.
llvm-svn: 360754
apple and manual indexing code were creating a DIERef in a bunch of
places. Though the code itself is not much, it is also easy to simplify
by factoring out the DIERef creation. In HashedNameToDIE I create a
conversion operator from DIEInfo to DIERef, and in ManualDWARFIndex I
just create the DIERef in a global variable up-front.
This also reduces the diff in follow-up patches which change how DIERefs
are constructed.
llvm-svn: 360669
Summary:
This patch implements the GetUnwindPlan interface (added in the previous
patch) for SymbolFileBreakpad, and uses it to generate unwind plans from
STACK CFI records in breakpad files.
We first perform a light-weight parse of the breakpad in order to build
up a map of regions covered by the unwind info so that we can later jump
to the right record when we need to unwind a specific function.
The actual parsing is relatively straight-forward, as the STACK CFI records
are just another (text) form of the eh_frame unwind instructions, and
the same goes for lldb's UnwindPlans. The newly-introduced
PostfixExpression API is used to convert the breakpad postfix
expressions into DWARF. The generated dwarf expressions are stored in a
BumpPtrAllocator, as the UnwindPlan does not take ownership of the
expression data it references (usually this is static data in an object
file, so special ownership is needed).
At this moment the generated unwind plans aren't used in the actual
unwind machinery (only in the image show-unwind command), but that is
coming in a separate patch.
Reviewers: amccarth, clayborg, markmentovai
Subscribers: aprantl, jasonmolenda, lldb-commits
Differential Revision: https://reviews.llvm.org/D61733
llvm-svn: 360574
Summary:
This patch implements missing case in PdbAstBuilder::CreateType for
LF_MFUNCTION. This is necessary, for example, in stack unwinding of struct
methods.
Reviewers: amccarth, aleksandr.urakov
Reviewed By: amccarth
Subscribers: abidh, teemperor, lldb-commits, leonid.mashinskiy
Differential Revision: https://reviews.llvm.org/D61128
llvm-svn: 360569
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
These two methods are very similar and various refactorizations need to modify
both similar ways.
One could also just remove GetCompileUnitAtOffset and make
GetCompileUnitContainingDIEOffset to also accept offset of the CU itself
(currently it accepts only DIE offsets after the CU header).
But that would be less safe regarding some internal sanity checking.
Further code refactorization has been suggested by Pavel Labath.
Differential Revision: https://reviews.llvm.org/D61498
llvm-svn: 360038
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
Summary:
This will fix a bug where during expression parsing we are not setting a CXXRecordDecl to not be passed in registers and the resulting code generation is wrong.
The DWARF attribute DW_CC_pass_by_reference tells us that we should not be passing in registers i.e. RAA_Indirect.
This change depends this clang change which fixes the fact that the ASTImporter does not copy RecordDeclBits for CXXRecordDecl: https://reviews.llvm.org/D61140
Differential Revision: https://reviews.llvm.org/D61146
llvm-svn: 359732
Summary:
The new dwarf generator is pretty much a verbatim copy of the one in
PDB.
In order to write a pdb-independent test for it, I needed to write a
dummy "symbol resolver", which (together with the fact that I'll need
one more for breakpad-specific resolution logic) prompted me to create a
more simple interface for algorithms which replace or "resolve"
SymbolNodes. The resolving algorithms in NativePDB have been updated to
make use of that too.
I have removed a couple of NativePDB tests which weren't testing
anything pdb-specific and where the tested functionality was covered by
the new format-agnostic tests I have added.
Reviewers: amccarth, clayborg, aleksandr.urakov
Subscribers: aprantl, markmentovai, lldb-commits, jasonmolenda, JDevlieghere
Differential Revision: https://reviews.llvm.org/D61056
llvm-svn: 359288
Summary:
When we encounter a templated function in the debug information, we
were creating an AST that looked like this:
FunctionTemplateDecl 0x12980ab90 <<invalid sloc>> <invalid sloc> foo<int>
|-TemplateTypeParmDecl 0x12980aad0 <<invalid sloc>> <invalid sloc> class depth 0 index 0 T
|-FunctionDecl 0x12980aa30 <<invalid sloc>> <invalid sloc> foo<int> 'int (int)' extern
| |-TemplateArgument type 'int'
| `-ParmVarDecl 0x12980a998 <<invalid sloc>> <invalid sloc> t1 'int'
`-FunctionDecl 0x12980aa30 <<invalid sloc>> <invalid sloc> foo<int> 'int (int)' extern
|-TemplateArgument type 'int'
`-ParmVarDecl 0x12980a998 <<invalid sloc>> <invalid sloc> t1 'int'
Note that the FunctionTemplateDecl has 2 children which are identical (as
in have the same address). This is not what Clang is doing:
FunctionTemplateDecl 0x7f89d206c6f8 </tmp/template.cpp:1:1, line:4:1> line:2:5 foo
|-TemplateTypeParmDecl 0x7f89d206c4a8 <line:1:10, col:19> col:19 referenced typename depth 0 index 0 T
|-FunctionDecl 0x7f89d206c660 <line:2:1, line:4:1> line:2:5 foo 'int (T)'
| `-ParmVarDecl 0x7f89d206c570 <col:9, col:11> col:11 t1 'T'
`-FunctionDecl 0x7f89d206cb60 <line:2:1, line:4:1> line:2:5 used foo 'int (int)'
|-TemplateArgument type 'int'
`-ParmVarDecl 0x7f89d206ca68 <col:9, col:11> col:11 t1 'int':'int'
The 2 chidlren are different and actually repesent different things: the first
one is the unspecialized version and the second one is specialized. (Just looking
at the names shows another major difference which is that we create the parent
with a name of "foo<int>" when it should be just "foo".)
The fact that we have those 2 identical children confuses the ClangImporter
and generates an infinite recursion (reported in https://llvm.org/pr41473).
We cannot create the unspecialized version as the debug information doesn't
contain a mapping from the template parameters to their use in the prototype.
This patch just creates 2 different FunctionDecls for those 2 children of the
FunctionTemplateDecl. This avoids the infinite recursion and allows us to
call functions. As the XFAILs in the added test show, we've still got issues
in our handling of templates. I believe they are mostly centered on the fact
that we create do not register "foo" as a template, but "foo<int>". This is
a bigger change that will need changes to the debug information generation.
I believe this change makes sense on its own.
Reviewers: shafik, clayborg, jingham
Subscribers: aprantl, javed.absar, kristof.beyls, lldb-commits
Differential Revision: https://reviews.llvm.org/D61044
llvm-svn: 359140
Summary:
The postfix expressions in PDB and breakpad symbol files are similar
enough that they can be parsed by the same parser. This patch
generalizes the parser in the NativePDB plugin and moves it into the
PostfixExpression file created in the previous commit (r358976).
The generalization consists of treating any unrecognised token as a
"symbol" node (previously these would only be created for tokens
starting with "$", and other token would abort the parse). This is
needed because breakpad symbols can also contain ".cfa" tokens, which
refer to the frame's CFA.
The cosmetic changes include:
- using a factory function instead of a class for creating nodes (this
is more generic as it allows the same BumpPtrAllocator to be used for
other things too)
- using dedicated function for parsing operator tokens instead of a
DenseMap (more efficient as we don't need to create the DenseMap every
time).
Reviewers: amccarth, clayborg, JDevlieghere, aleksandr.urakov
Subscribers: jasonmolenda, lldb-commits, markmentovai, mgorny
Differential Revision: https://reviews.llvm.org/D61003
llvm-svn: 359073
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
Summary:
The NativePDB plugin contains code to convert "programs" describing the
layout of function frames into dwarf (for easier interaction with the
rest of lldb). This functionality is useful for the Breakpad plugin too,
as it contains the same kind of expressions (because breakpad info is
generated from pdb files).
In this patch, I move the core classes of this code into a common place,
where it can be used from both files. Previously, these were the details
of the implementation, but here I am exposing them (instead of just a
single "string->string" conversion function), as breakpad will need to
use these in a slightly different way. The reason for that is that
breakpad files generated from dwarf expressions use a slightly different
syntax, although most of the core code can be reused with a bit of
thought.
This is also the reason why I am not moving the parsing or dwarf
generation bits, as they will need to be generalized a bit before
they're usable for both scenarios.
This patch should be NFC, modulo renaming the moved entities to more
neutral names.
The reason I am moving this to the "Symbol" library, is because both
customers will be "Symbol"Files, and also the unwinding code lives in
the Symbol library. From a purely dependency standpoint this code will
probably be standalone, and so it could be moved all the way to Utility,
but that seems too low for this kind of functionality.
Reviewers: jasonmolenda, amccarth, clayborg, JDevlieghere, aleksandr.urakov
Subscribers: aprantl, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D60599
llvm-svn: 358976
Summary:
This patch adds anonymous namespaces support to the native PDB plugin.
I had to reference from the main function variables of the types that are inside
of the anonymous namespace to include them in debug info. Without the references
they are not included. I think it's because they are static, then are visible
only in the current translation unit, so they are not needed without any
references to them.
There is also the problem case with variables of types that are nested in
template structs. For now I've left FIXME in the test because this case is not
related to the change.
Reviewers: zturner, asmith, labath, stella.stamenova, amccarth
Reviewed By: amccarth
Subscribers: zloyrobot, aprantl, teemperor, lldb-commits, leonid.mashinskiy
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60817
llvm-svn: 358873
Summary:
This patch attempts to solve two issues made this code hard to follow
for me.
The first issue was that a lot of what these visitors do is mutate the
AST. The visitor pattern is not particularly good for that because by
the time you have performed the dynamic type dispatch, it's too late to
go back to the parent node, and change its pointer. The previous code
dealt with that relatively elegantly, but it still meant that one had to
perform manual type checks, which is what the visitor pattern is
supposed to avoid.
The second issue was not being able to return values from the Visit
functions, which meant that one had to store function results in member
variables (a common problem with visitor patterns).
Here, I solve both problems by making the visitor use a type switch
instead of going through double dispatch on the visited object. This
allows one to parameterize the visitor based on the return type and pass
function results as function results. The mutation is fascilitated by
having each Visit function take two arguments -- a reference to the
object itself (with the correct dynamic type), and a reference to the
parent's pointer to this object.
Although this wasn't my explicit goal here, the fact that we're not
using virtual dispatch anymore allows us to make the AST nodes
trivially destructible, which is a good thing, since we were not
destroying them anyway.
Reviewers: aleksandr.urakov, amccarth
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60410
llvm-svn: 358261
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
Summary:
The code was passing pointers around, expecting they would be not null.
In c++ it is possible to convey this notion explicitly by using a
reference instead.
Not all uses of pointers could be converted to references (e.g. one
can't store references in a container), but this will at least make it
locally obvious that code is dealing with nonnull pointers.
Reviewers: aleksandr.urakov, amccarth
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60271
llvm-svn: 357744
Summary:
Now CVType and CVSymbol are effectively type-safe wrappers around
ArrayRef<uint8_t>. Make the kind() accessor load it from the
RecordPrefix, which is the same for types and symbols.
Reviewers: zturner, aganea
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60018
llvm-svn: 357658
A recent patch to LLD started emitting information about import modules.
These are represented as compile units in the PDB, but with no
additional debug info. This was confusing the native pdb reader, who
expected that the debug info stream be present.
This should fix failing tests on the Windows bots.
llvm-svn: 357513
Summary:
This refactors moves the register name->number resolution out of the
FPOProgramNodeRegisterRef class. Instead I create a special
FPOProgramNodeSymbol class, which holds unresolved symbols, and move the
resolution into the ResolveRegisterRefs visitor.
The background here is that I'd like to use this code for Breakpad
unwind info, which uses similar syntax to describe unwind info. For
example, a simple breakpad unwind program might look like:
.cfa: $esp 8 + $ebp: .cfa 8 - ^
To be able to do this, I need to be able to customize register
resolving, as that is presently hardcoded to use codeview register
names, but breakpad supports a lot more architectures with different
register names. Moving the resolution into a separate class will allow
each user to use a different resolution logic.
Reviewers: aleksandr.urakov, zturner, amccarth
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D60068
llvm-svn: 357455
Summary:
An TranslationUnitDecl was being brought in from the clang::ASTContext
which required clang specific code to exist in SymbolFilePDB.
Since it was unused we can just get rid of it along with the clang
specific code.
Reviewers: rnk, zturner, compnerd
Reviewed By: compnerd
Subscribers: jdoerfert
Differential Revision: https://reviews.llvm.org/D59804
llvm-svn: 357113
This is diagnosed by gcc-8. The ValueType struct already has a default
constructor which performs zero-initialization, so we can just call that
instead of using memset.
llvm-svn: 357056
Summary:
Instead of assuming that the language is C++ instead check the compunit
for the language it received from the debug info.
Subscribers: aprantl, jdoerfert
Differential Revision: https://reviews.llvm.org/D59805
llvm-svn: 357044
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
Most of these are Dump functions that are never called, but there
is one instance of entire unused classes (DWARFDebugMacinfo and
DWARFDebugMacinfoEntry) which are also unreferenced in the codebase).
Differential Revision: https://reviews.llvm.org/D59276
llvm-svn: 356490
These log statements have questionable value, and hinder the effort
of separating the high and low level DWARF parsing interfaces inside
of LLDB. Removing them for now, and if/when we need such log statements
again in the future, we can add them back (if possible) or introduce a
mechanism for logging from the low-level interface in such a way that it
isn't coupled to the high level interface.
Differential Revision: https://reviews.llvm.org/D59498
llvm-svn: 356469
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
This is not used outside of the private implementation of the class,
so hiding in the implementation file is a nice way of simplifying
the external interface.
Differential Revision: https://reviews.llvm.org/D59164
llvm-svn: 355973
ICF can cause multiple symbols to start at the same virtual address.
I plan to handle this shortly, but I wanted to correct the comment for
now.
Deleted an obsolete comment about adjusting the offset for the magic
number at the beginning of the debug info stream. This adjustment is
handled at a lower level now.
llvm-svn: 355943
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
Summary: DW_OP_GNU_addr_index has been renamed as DW_OP_addrx in the standard. clang produces DW_OP_addrx tags and with this change lldb starts to process them.
Reviewers: aprantl, jingham, davide, clayborg, serge-sans-paille
Reviewed By: aprantl
Subscribers: jdoerfert, dblaikie, labath, shafik, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D59004
llvm-svn: 355629
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
Summary:
This file implements some general purpose data structures, and so it
belongs to the Utility module.
Reviewers: zturner, jingham, JDevlieghere, clayborg, espindola
Subscribers: emaste, mgorny, javed.absar, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D58970
llvm-svn: 355509
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
COFF files are modelled in lldb as having one big container section
spanning the entire module image, with the actual sections being
subsections of that. In this model, the base address is simply the
address of the first byte of that section.
This also removes the hack where ObjectFilePECOFF was using the
m_file_offset field to communicate this information. Using file offset
for this purpose is completely wrong, as that is supposed to indicate
where is this ObjectFile located in the file on disk. This field is only
meaningful for fat binaries, and should normally be 0.
Both PDB plugins have been updated to use GetBaseAddress instead of
GetFileOffset.
llvm-svn: 354258
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
Summary:
This is coming from the discussion in D55356 (the most interesting part
happened on the mailing list, so it isn't reflected on the review page).
In short the issue is that lldb assumes that all bytes of a module image
in memory will be backed by a "section". This isn't the case for PECOFF
files because the initial bytes of the module image will contain the
file header, which does not correspond to any normal section in the
file. In particular, this means it is not possible to implement
GetBaseAddress function for PECOFF files, because that's supposed point
to the first byte of that header.
If my (limited) understanding of how PECOFF files work is correct, then
the OS is expecded to load the entire module into one continuous chunk
of memory. The address of that chunk (+/- ASLR) is given by the "image
base" field in the COFF header, and it's size by "image size". All of
the COFF sections are then loaded into this range.
If that's true, then we can model this behavior in lldb by creating a
"container" section to represent the entire module image, and then place
other sections inside that. This would make be consistent with how MachO
and ELF files are modelled (except that those can have multiple
top-level containers as they can be loaded into multiple discontinuous
chunks of memory).
This change required a small number of fixups in the PDB plugins, which
assumed a certain order of sections within the object file (which
obivously changes now). I fix this by changing the lookup code to use
section IDs (which are unchanged) instead of indexes. This has the nice
benefit of removing spurious -1s in the plugins as the section IDs in
the pdbs match the 1-based section IDs in the COFF plugin.
Besides making the implementation of GetBaseAddress possible, this also
improves the lookup of addresses in the gaps between the object file
sections, which will now be correctly resolved as belonging to the
object file.
Reviewers: zturner, amccarth, stella.stamenova, clayborg, lemo
Reviewed By: clayborg, lemo
Subscribers: JDevlieghere, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D56537
llvm-svn: 353916
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
Summary:
This patch makes virtual bases to be added in the correct order to the bases
list. It is important because `VTableContext` (`MicrosoftVTableContext` in our
case) uses then the order of virtual bases in the list to restore the virtual
table indexes. These indexes are used then to resolve the layout of the virtual
bases.
We haven't enough information about offsets of virtual bases regarding to the
object (moreover, in a common case we can't rely on such information, see the
example here: https://reviews.llvm.org/D53506#1272306 ), but there should be
enough information to restore the layout of the virtual bases from the indexes
in runtime. After D53506 this information is used whenever possible, so there
should be no problems with virtual bases' fields reading.
Reviewers: zturner, rnk, stella.stamenova
Subscribers: abidh, teemperor, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D56904
llvm-svn: 353806
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
Summary:
This adds support for auto-detection of path style to SymbolFileBreakpad
(similar to how r351328 did the same for DWARF). We guess each file
entry separately, as we have no idea which file came from which compile
units (and different compile units can have different path styles). The
breakpad generates should have already converted the paths to absolute
ones, so this guess should be reasonable accurate, but as always with
these kinds of things, it is hard to give guarantees about anything.
In an attempt to bring some unity to the path guessing logic, I move the
guessing logic from inside SymbolFileDWARF into the FileSpec class and
have both symbol files use it to implent their desired behavior.
Reviewers: clayborg, lemo, JDevlieghere
Subscribers: aprantl, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D57895
llvm-svn: 353702
Summary:
This patch teaches SymbolFileBreakpad to parse the line information in
breakpad files and present it to lldb.
The trickiest question here was what kind of "compile units" to present
to lldb, as there really isn't enough information in breakpad files to
correctly reconstruct those.
A couple of options were considered
- have the entire file be one compile unit
- have one compile unit for each FILE record
- have one compile unit for each FUNC record
The main drawback of the first approach is that all of the files would
be considered "headers" by lldb, and so they wouldn't be searched if
target.inline-breakpoint-strategy=never. The single compile unit would
also be huge, and there isn't a good way to name it.
The second approach will create mostly correct compile units for cpp
files, but it will still be wrong for headers. However, the biggest
drawback here seemed to be the fact that this can cause a compile unit
to change mid-function (for example when a function from another file is
inlined or another file is #included into a function). While I don't
know of any specific thing that would break in this case, it does sound
like a thing that we should avoid.
In the end, we chose the third option, as it didn't seem to have any
major disadvantages, though it was not ideal either. One disadvantage
here is that this generates a large number of compile units, and there
is still a question on how to name it. We chose to simply name it after
the first line record in that function. This should be correct 99.99% of
the time, though it can produce somewhat strange results if the very
first line record comes from an #included file.
Reviewers: clayborg, zturner, lemo, markmentovai
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56595
llvm-svn: 353404
stored relative to VFRAME
Summary:
This patch makes LLDB able to retrieve proper values for function arguments and
local variables stored in PDB relative to VFRAME register.
Patch contains retrieval of corresponding FPO table entries from PDB and a
generic translator from FPO programs to DWARF expressions to get correct VFRAME
value.
Patch also improves variables-locations.test and makes this test passable on
x86.
Patch By: leonid.mashinsky
Reviewers: zturner, asmith, stella.stamenova, aleksandr.urakov
Reviewed By: zturner
Subscribers: arphaman, labath, mgorny, aprantl, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D55122
llvm-svn: 352845
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
Summary:
This patch adds the basic support of methods reconstruction by native PDB
plugin. It contains only most obvious changes (it processes LF_ONEMETHOD and
LF_METHOD records), some things still remain unsolved:
- mangled names retrieving;
- support of template methods.
Reviewers: zturner, labath, lemo, stella.stamenova
Reviewed by: zturner
Differential Revision: https://reviews.llvm.org/D56126
llvm-svn: 352464
Summary:
This addresses the issues raised in D56844. It removes the accessors from the
breakpad record structures by making the fields public. Also, I refactor the
UUID parsing code to remove hard-coded constants.
Reviewers: lemo
Subscribers: clayborg, lldb-commits
Differential Revision: https://reviews.llvm.org/D57037
llvm-svn: 352021
This patch extends SymbolFileBreakpad::AddSymbols to include the symbols
from the FUNC records too. These symbols come from the debug info and
have a size associated with them, so they are given preference in case
there is a PUBLIC record for the same address.
To achieve this, I first pre-process the symbols into a temporary
DenseMap, and then insert the uniqued symbols into the module's symtab.
Reviewers: clayborg, lemo, zturner
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56590
llvm-svn: 351781
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:
This centralizes parsing of breakpad records, which was previously
spread out over ObjectFileBreakpad and SymbolFileBreakpad.
For each record type X there is a separate breakpad::XRecord class, and
an associated parse function. The classes just store the information in
the breakpad records in a more accessible form. It is up to the users to
determine what to do with that data.
This separation also made it possible to write some targeted tests for
the parsing code, which was previously unaccessible, so I write a couple
of those too.
Reviewers: clayborg, lemo, zturner
Reviewed By: clayborg
Subscribers: mgorny, fedor.sergeev, lldb-commits
Differential Revision: https://reviews.llvm.org/D56844
llvm-svn: 351541
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
The code in LLDB assumes that CompilerType and friends use the size 0
as a sentinel value to signal an error. This works for C++, where no
zero-sized type exists, but in many other programming languages
(including I believe C) types of size zero are possible and even
common. This is a particular pain point in swift-lldb, where extra
code exists to double-check that a type is *really* of size zero and
not an error at various locations.
To remedy this situation, this patch starts by converting
CompilerType::getBitSize() and getByteSize() to return an optional
result. To avoid wasting space, I hand-rolled my own optional data
type assuming that no type is larger than what fits into 63
bits. Follow-up patches would make similar changes to the ValueObject
hierarchy.
rdar://problem/47178964
Differential Revision: https://reviews.llvm.org/D56688
llvm-svn: 351214
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
Summary:
This commit adds the glue code necessary to integrate the
SymbolFileBreakpad into the plugin system. Most of the methods are
stubbed out. The only method implemented method is AddSymbols, which
parses the PUBLIC "section" of the breakpad "object file", and fills out
the Module's symtab.
To enable testing this, I've made two additional changes:
- dump Symtab from the SymbolVendor class. The symtab was already being
dumped as a part of the object file dump, but that happened before
symbol vendor kicked in, so it did not reflect any symbols added
there.
- add ability to explicitly specify the external symbol file in
lldb-test (so that the object file could be linked with the breakpad
symbol file). To make things simpler, I've changed lldb-test from
consuming multiple inputs (and dumping their symbols) to having it
just process a single file per invocation. This was not a problem
since everyone was using it that way already.
Reviewers: clayborg, zturner, lemo, markmentovai, amccarth
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56173
llvm-svn: 350924
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
Typedefs are represented as S_UDT records in the globals stream. This
creates a strange situation where "types" are actually represented as
"symbols", so they need special handling.
In order to test this, we don't just use lldb and print out some
variables causing the AST to get created, because variables whose type
is a typedef will have debug info referencing the original type, not the
typedef. So we use lldb-test instead which will parse all debug info in
the entire file. This exposed some problems with lldb-test and the
native reader, mainly that certain types of obscure symbols which we can
find when iterating every single record would trigger crashes. These
have been fixed as well so that lldb-test can be used to test this
functionality.
Differential Revision: https://reviews.llvm.org/D56461
llvm-svn: 350888
ParseDeclsForContext was originally created to serve the very specific
case where the context is a function block. It was never intended to be
used for arbitrary DeclContexts, however due to the generic name, the
DWARF and PDB plugins implemented it in this way "just in case". Then,
lldb-test came along and decided to use it in that way.
Related to this, there are a set of functions in the SymbolFile class
interface whose requirements and expectations are not documented. For
example, if you call ParseCompileUnitFunctions, there's an inherent
requirement that you create entries in the underlying clang AST for
these functions as well as their signature types, because in order to
create an lldb_private::Function object, you have to pass it a
CompilerType for the parameter representing the signature.
On the other hand, there is no similar requirement (either inherent or
documented) if one were to call ParseDeclsForContext. Specifically, if
one calls ParseDeclsForContext, and some variable declarations, types,
and other things are added to the clang AST, is it necessary to create
lldb::Variable, lldb::Type, etc objects representing them? Nobody knows.
There is, however, an accidental requirement, because since all of the
plugins implemented this just in case, lldb-test came along and used
ParsedDeclsForContext, and then wrote check lines that depended on this.
When I went to try and implemented the NativePDB reader, I did not
adhere to this (in fact, from a layering perspective I went out of my
way to avoid it), and as a result the existing DIA PDB tests don't work
when the native PDB reader is enabled, because they expect that calling
ParseDeclsForContext will modify the *module's* view of symbols, and not
just the internal AST.
All of this confusion, however, can be avoided if we simply stick to
using ParseDeclsForContext for its original intended use case (blocks),
and use a different function (ParseAllDebugSymbols) for its intended use
case which is, unsuprisingly, to parse all the debug symbols (which is
all lldb-test really wanted to do anyway).
In the future, I would like to change ParseDeclsForContext to
ParseDeclsForFunctionBlock, then delete all of the dead code inside that
handles other types of DeclContexts (and probably even assert if the
DeclContext is anything other than a block).
A few PDB tests needed to be fixed up as a result of this, and this also
exposed a couple of bugs in the DIA PDB reader (doesn't matter much
since it should be going away soon, but worth mentioning) where the
appropriate AST entries weren't being created always.
Differential Revision: https://reviews.llvm.org/D56418
llvm-svn: 350764
Summary:
The main difference between the classes was supposed to be the fact that
one is backed by llvm::SmallVector, and the other by std::vector.
However, over the years, they have accumulated various other differences
too.
This essentially removes the std::vector version, as that is pretty much
identical to llvm::SmallVector<T, 0>, and combines their interfaces. It
does not attempt to do a more significant refactoring, even though there
is still a lot of duplication in this file, as it is hard to tell which
quirk of some API is depended on by somebody (and, a previous, more
ambitious attempt at this in D16769 has failed).
I also add some tests, including one which demonstrates one of the
quirks/bugs of the API I have noticed in the process.
Reviewers: clayborg, teemperor, tberghammer
Subscribers: mgorny, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56170
llvm-svn: 350380
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 is a first step towards getting lldb-test symbols working
with the native plugin. There is a remaining issue, which is
that the plugin expects that ParseDeclsForContext will also
create lldb symbols rather than just the decls, but the native
pdb plugin doesn't currently do this. This will be addressed
in a followup patch.
llvm-svn: 350243
There were several problems preventing this from working. The
first is that when the PDB had an absolute path to the main
source file, we would construct an invalid path by prepending the
compilation directory to it anyway. So we needed to check if the
path is already absolute first.
Second, LLDB assumes that the zero'th item in the support file list
is the main compilation unit. We were respecting this requirement,
but LLDB *also* requires that file to appear somewhere in the list
starting from index 1 as well. So the main compilation file should
appear in the support file list twice. And when parsing a line
table, it expects the LineEntry records to be constructed using
the 1-based index. With these two fixes we can now set breakpoints
by file and line using the native PDB reader.
llvm-svn: 350240
Summary:
r346165 introduced a bug, where we would fail to parse the size of an
array if that size happened to match an existing die offset.
The logic was:
if (DWARFDIE count = die.GetReferencedDie(DW_AT_count))
num_elements = compute_vla_size(count);
else
num_elements = die.GetUsigned(DW_AT_count); // a fixed-size array
The problem with this logic was that GetReferencedDie did not take the
form class of the attribute into account, and would happily return a die
reference for any form, if its value happened to match some die.
As this behavior is inconsistent with how llvm's DWARFFormValue class
operates, I chose to fix the problem by making our version of this class
match the llvm behavior. For this to work, I had to add an explicit form
class check to the .apple_XXX tables parsing code, because they do
(incorrectly?) use data forms as die references.
Reviewers: aprantl, clayborg
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D55991
llvm-svn: 350086
Jonas Devlieghere