| Age | Commit message (Collapse) | Author |
|---|
|
This reland 945aa520ef07a3edb655f3f38e4c3023658dd623 with fixes.
This reverts commit 10bc3362a1a8a3df2660bf65db0ec1ccab646e1b.
|
|
This reverts commit 945aa520ef07a3edb655f3f38e4c3023658dd623.
This commit broke the windows lldb bot.
|
|
This adds inline function support to NativePDB by parsing S_INLINESITE records
to retrieve inlinee line info and add them into line table at `ParseLineTable`.
Differential Revision: https://reviews.llvm.org/D116845
|
|
Identified with readability-redundant-control-flow.
|
|
I don't see a reason why not to. If we allows lookup functions by full names,
I can change the test case in D113930 to use `lldb-test symbols --find=function --name=full::name --function-flags=full ...`,
though the duplicate method decl prolem is still there for `lldb-test symbols --dump-ast`.
That's a seprate bug, we can fix it later.
Differential Revision: https://reviews.llvm.org/D114467
|
|
`image lookup -a ` doesn't work because the compilands list is always empty.
Create CU at given index if doesn't exit.
Differential Revision: https://reviews.llvm.org/D113821
|
|
SymbolFile plugin names
|
|
The new key/value pairs that are added to each module's stats are:
"debugInfoByteSize": The size in bytes of debug info for each module.
"debugInfoIndexTime": The time in seconds that it took to index the debug info.
"debugInfoParseTime": The time in seconds that debug info had to be parsed.
At the top level we add up all of the debug info size, parse time and index time with the following keys:
"totalDebugInfoByteSize": The size in bytes of all debug info in all modules.
"totalDebugInfoIndexTime": The time in seconds that it took to index all debug info if it was indexed for all modules.
"totalDebugInfoParseTime": The time in seconds that debug info was parsed for all modules.
Differential Revision: https://reviews.llvm.org/D112501
|
|
There is no reason why this function should be returning a ConstString.
While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.
I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.
Differential Revision: https://reviews.llvm.org/D111877
|
|
In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.
Differential Revision: https://reviews.llvm.org/D109600
|
|
Replace default bodies of special member functions with = default;
$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html
Differential revision: https://reviews.llvm.org/D104041
|
|
This patch refactors a good part of the code base turning the usual
FileSpec, Line, Column, CheckInlines, ExactMatch arguments into a
SourceLocationSpec object.
This change is required for a following patch that will add handling of the
column line information when doing symbol resolution.
Differential Revision: https://reviews.llvm.org/D100965
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
`InsertSequence` doesn't take ownership of the pointer so releasing this pointer
is just leaking memory.
Follow up to D100806 that was fixing other leak sanitizer test failures
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D100846
|
|
To allow loading PDB file with `target symbols add` command.
Differential Revision: https://reviews.llvm.org/D89812
|
|
|
|
This makes it symmetric with all other flags and makes it easier to
not forget to initialize it.
https://reviews.llvm.org/D89351
|
|
When loading a PE/COFF target, the associated PDB file often wasn't
found. The executable module contains a path for the associated PDB
file, but people often debug from a different directory than the one
their build system uses. (This is especially common in post-mortem
and cross platform debugging.)
Suppose the COFF executable being debugged is `~/proj/foo.exe`, but
it was built elsewhere and refers to `D:\remote\build\env\foobar.pdb`,
LLDB wouldn't find it.
With this change, if no file exists at the PDB path, LLDB will look
in the executable directory for a PDB file that matches the name of
the one it expected (e.g., `~/proj/foobar.pdb`). If found, the PDB
is subject to the same matching criteria (GUIDs and age) as would
have been used had it been in the original location.
This same-directory-as-the-binary rule is commonly used by debuggers
on Windows.
Differential Review: https://reviews.llvm.org/D84815
|
|
This patch has no effect for C and C++. In more dynamic languages,
such as Objective-C and Swift GetByteSize() needs to call into the
language runtime, so it's important to pass one in where possible. My
primary motivation for this is some work I'm doing on the Swift
branch, however, it looks like we are also seeing warnings in
Objective-C that this may resolve. Everything in the SymbolFile
hierarchy still passes in nullptrs, because we don't have an execution
context in SymbolFile, since SymbolFile transcends processes.
Differential Revision: https://reviews.llvm.org/D84267
|
|
This reverts commit 101fbc01382edd89ea7b671104c68b30b2446cc0.
Remove leftover debugging attribute.
Update LLDB as well, which was missed before.
|
|
pointers
Summary:
All of our lookup APIs either use `CompilerDeclContext &` or `CompilerDeclContext *` semi-randomly it seems.
This leads to us constantly converting between those two types (and doing nullptr checks when going from
pointer to reference). It also leads to the confusing situation where we have two possible ways to express
that we don't have a CompilerDeclContex: either a nullptr or an invalid CompilerDeclContext (aka a default
constructed CompilerDeclContext).
This moves all APIs to use references and gets rid of all the nullptr checks and conversions.
Reviewers: labath, mib, shafik
Reviewed By: labath, shafik
Subscribers: shafik, arphaman, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74607
|
|
- Don't initialize NativePDB.
- Initialize ProcessWindows after any Process*Core plugins.
- Don't initialize DynamicLoaderDarwinKernel on non-Darwin platforms.
|
|
plugin"
This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.
The previously landed patch got reverted because it was lacking:
(1) A plugin definition for the Objective-C language runtime,
(2) The dependency between the Static and WASM dynamic loader,
(3) Explicit initialization of ScriptInterpreterNone for lldb-test.
All issues have been addressed in this patch.
Differential revision: https://reviews.llvm.org/D73067
|
|
plugin"
This temporarily reverts commit 7d6da329dee1eda1761430d9097d1323f32c4c0c
because it's causing test failures on the bots.
|
|
This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.
Differential revision: https://reviews.llvm.org/D73067
|
|
Summary:
This change represents the move of ClangASTImporter, ClangASTMetadata,
ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and
TypeSystemClang from lldbSource to lldbPluginExpressionParserClang.h
This explicitly removes knowledge of clang internals from lldbSymbol,
moving towards a more generic core implementation of lldb.
Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafik
Subscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73661
|
|
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
|
|
This reverts commit bb73210ba9f16c1516f564235c86cbddccd1bd6d due to
failures on the windows bot.
|
|
The old method of adding line sequences one by one can easily go
quadratic if the sequences are not perfectly sorted. The equivalent
change in DWARF brought a considerable improvement in line table
parsing. It is not clear if the same will be the case for PDB, but this
does bring us a step closer towards removing the dangerous API.
|
|
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
|
|
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
|
|
These files only need the definition of ClangASTMetadata (which was
previously in the ClangASTSourceCommon.h) or don't need the include at all.
|
|
DWARF5 line tables
Summary:
Lldb's "format-independent" debug info made use of the fact that DWARF
(<=4) did not use the file index zero, and reused the support file index
zero for storing the compile unit name.
While this provided some convenience for DWARF<=4, it meant that the PDB
plugin needed to artificially remap file indices in order to free up
index 0. Furthermore, DWARF v5 make file index 0 legal, which meant that
similar remapping would be needed in the dwarf plugin too.
What this patch does instead is remove the requirement of having the
compile unit name in the index 0. It is not that useful since the name
can always be fetched from the CompileUnit object. Remapping code in the
pdb plugin(s) has been removed or simplified.
DWARF plugin has started inserting an empty FileSpec at index 0 to
ensure the indices keep matching up (in case of DWARF<=4). For DWARF5,
we insert the file 0 from the line table.
I add a test to ensure we can correctly lookup line table entries
referencing file 0, and in particular the case where the file 0 is also
duplicated in another file entry, as this is how clang produces line
tables in some circumstances (see pr44170). Though this is probably a
bug in clang, this is not forbidden by DWARF, and lldb already has
support for that in some (but not all) cases -- this adds a test for the
code path which was not fixed in this patch.
Reviewers: clayborg, JDevlieghere, jdoerfert
Subscribers: aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70954
|
|
Due to alginment and packing using separate members takes up the same
amount of space, but makes it far less cumbersome to deal with it in
constructors etc.
|
|
Differential Revision: https://reviews.llvm.org/D70322
|
|
This is basically the same bug as in r260434.
SymbolFileDWARF::FindTypes has exponential worst-case when digging
through dependency DAG of .pcm files because each object file and .pcm
file may depend on an already-visited .pcm file, which may again have
dependencies. Fixed here by carrying a set of already visited
SymbolFiles around.
rdar://problem/56993424
Differential Revision: https://reviews.llvm.org/D70106
|
|
This patch removes the size_t return value and the append parameter
from the remainder of the Find.* functions in LLDB's internal API. As
in the previous patches, this is motivated by the fact that these
parameters aren't really used, and in the case of the append parameter
were frequently implemented incorrectly.
Differential Revision: https://reviews.llvm.org/D69119
llvm-svn: 375160
|
|
llvm-svn: 374587
|
|
In r368345 I accidentally introduced a regression that would
over-report the number of matches found by FindTypes if the
DeclContext Filter was hit.
This patch simply removes the size_t return parameter altogether —
it's not that useful.
rdar://problem/55500457
Differential Revision: https://reviews.llvm.org/D68169
llvm-svn: 373344
|
|
I noticed that SymbolFileDWARFDebugMap::FindTypes was implementing it
incorrectly (passing append=false in a for-loop to recursive calls to
FindTypes would yield only the very last set of results), but instead
of fixing it, removing it seemed like an even better option.
rdar://problem/54412692
Differential Revision: https://reviews.llvm.org/D68171
llvm-svn: 373224
|
|
This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.
In multi-language projects it is extremely common to have, e.g., a
Clang type and a similarly-named rendition of that same type in
another language. When searching for a type It is much cheaper to pass
a set of supported languages to the SymbolFile than having it
materialize every result and then rejecting the materialized types
that have the wrong language.
Differential Revision: https://reviews.llvm.org/D66546
<rdar://problem/54471165>
This reapplies r369690 with a previously missing constructor for LanguageSet.
llvm-svn: 369710
|
|
This reverts r369690 (git commit aa3a564efa6b5fff2129f81a4041069a0233168f)
llvm-svn: 369702
|
|
This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.
In multi-language projects it is extremely common to have, e.g., a
Clang type and a similarly-named rendition of that same type in
another language. When searching for a type It is much cheaper to pass
a set of supported languages to the SymbolFile than having it
materialize every result and then rejecting the materialized types
that have the wrong language.
Differential Revision: https://reviews.llvm.org/D66546
<rdar://problem/54471165>
llvm-svn: 369690
|
|
This patch generalizes the FindTypes with CompilerContext interface to
support looking up a type of unknown kind by name, as well as looking
up a type inside an unspecified submodule. These features are
motivated by the Swift branch, but are fully tested via unit tests and
lldb-test on llvm.org. Specifically, this patch adds an AnyModule and
an AnyType CompilerContext kind.
Differential Revision: https://reviews.llvm.org/D66507
rdar://problem/54471165
llvm-svn: 369555
|
|
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
|
|
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
|
|
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
|
|
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:
Similarly to the compile unit lists, the list of types can also be
managed by the symbol file itself.
Since the only purpose of this list seems to be to maintain an owning
reference to all the types a symbol file has created (items are only
ever added to the list, never retrieved), I remove the passthrough
functions in SymbolVendor and Module. I also tighten the interface of
the function (return a reference instead of a pointer, make it protected
instead of public).
Reviewers: clayborg, JDevlieghere, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D65135
llvm-svn: 366994
|
|
Summary:
SymbolFile classes are responsible for creating CompileUnit instances
and they already need to have a notion of the id<->CompileUnit mapping
(because of APIs like ParseCompileUnitAtIndex). However, the
SymbolVendor has remained as the thing responsible for caching created
units (which the SymbolFiles were calling via convoluted constructs like
"m_obj_file->GetModule()->GetSymbolVendor()->SetCompileUnitAtIndex(...)").
This patch moves the responsibility of caching the units into the
SymbolFile class. It does this by moving the implementation of
SymbolVendor::{GetNumCompileUnits,GetCompileUnitAtIndex} into the
equivalent SymbolFile functions. The SymbolVendor functions become just
a passthrough much like the rest of SymbolVendor.
The original implementations of SymbolFile::GetNumCompileUnits is moved
to "CalculateNumCompileUnits", and are made protected, as the "Get"
function is the external api of the class.
SymbolFile::ParseCompileUnitAtIndex is made protected for the same
reason.
This is the first step in removing the SymbolVendor indirection, as
proposed in
<http://lists.llvm.org/pipermail/lldb-dev/2019-June/015071.html>. After
removing all interesting logic from the SymbolVendor class, I'll proceed
with removing the indirection itself.
Reviewers: clayborg, jingham, JDevlieghere
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D65089
llvm-svn: 366791
|
