| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
The 'asynchronously' argument to both GetLLDBCommandsFromIOHandler and
GetPythonCommandsFromIOHandler is true for all call sites. This commit
simplifies the API by dropping it and giving the baton a default
argument.
|
|
|
|
|
|
| |
These are the last sections not managed by the DWARFContext object. I
also introduce separate SectionType enums for dwo section variants, as
this is necessary for proper handling of single-file split dwarf.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a failing testcase on Fedora 30 x86_64 (regression Fedora 29->30):
PASS:
./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit
* frame #0: 0x00007ffff7aa6e75 libc.so.6`__GI_raise + 325
frame #1: 0x00007ffff7a91895 libc.so.6`__GI_abort + 295
frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2
frame #3: 0x000000000040113a a.out`func_b at main.c:18:2
frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2
frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2
frame #6: 0x00007ffff7a92f33 libc.so.6`__libc_start_main + 243
frame #7: 0x000000000040106e a.out`_start + 46
vs.
FAIL - unrecognized abort() function:
./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit
* frame #0: 0x00007ffff7aa6e75 libc.so.6`.annobin_raise.c + 325
frame #1: 0x00007ffff7a91895 libc.so.6`.annobin_loadmsgcat.c_end.unlikely + 295
frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2
frame #3: 0x000000000040113a a.out`func_b at main.c:18:2
frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2
frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2
frame #6: 0x00007ffff7a92f33 libc.so.6`.annobin_libc_start.c + 243
frame #7: 0x000000000040106e a.out`.annobin_init.c.hot + 46
The extra ELF symbols are there due to Annobin (I did not investigate why this
problem happened specifically since F-30 and not since F-28).
It is due to:
Symbol table '.dynsym' contains 2361 entries:
Valu e Size Type Bind Vis Name
0000000000022769 5 FUNC LOCAL DEFAULT _nl_load_domain.cold
000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_abort.c.unlikely
...
000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_loadmsgcat.c_end.unlikely
...
000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_textdomain.c_end.unlikely
000000000002276e 548 FUNC GLOBAL DEFAULT abort
000000000002276e 548 FUNC GLOBAL DEFAULT abort@@GLIBC_2.2.5
000000000002276e 548 FUNC LOCAL DEFAULT __GI_abort
0000000000022992 0 NOTYPE LOCAL HIDDEN .annobin_abort.c_end.unlikely
GDB has some more complicated preferences between overlapping and/or sharing
address symbols, I have made here so far the most simple fix for this case.
Differential revision: https://reviews.llvm.org/D63540
|
|
|
|
|
|
|
| |
I modified the SBAPI under the assumption that nobody was using the old
API yet. However, that turns out to be false. So instead of adding the
deafault argument I've reintroduced the old API and made the new one an
overload.
|
|
|
|
|
|
|
|
|
|
|
| |
As suggested by @labath extended RangeDataVector so that user can provide
custom sorting of the Entry's `data' field for D63540.
https://reviews.llvm.org/D63540
RangeData functions were used just by RangeDataVector (=after I removed them
LLDB still builds fine) which no longer uses them so I removed them.
Differential revision: https://reviews.llvm.org/D72460
|
|
|
|
|
|
|
| |
Gcc produces this (technically correct) warning when storing an
explicitly-sized enum in a bitfield. Surpress that by changing the type
of the bitfield to an integer. The same approach is used elsewhere in
llvm (e.g. 56b5eab12).
|
|
|
|
|
| |
instead of a function pointer + void*, take a std::function. This
removes a bunch of repetitive, unsafe void* casts.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Our code was expecting that a single (symbol) file contains only one
kind of location lists. This is not correct (on non-apple platforms, at
least) as a file can compile units with different dwarf versions.
This patch moves the deteremination of location list flavour down to the
compile unit level, fixing this problem. I have also tried to rougly
align the code with the llvm DWARFUnit. Fully matching the API is not
possible because of how lldb's DWARFExpression lives separately from the
rest of the DWARF code, but this is at least a step in the right
direction.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: dblaikie, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71751
|
|
|
|
|
|
|
|
|
|
|
| |
Creating an ASTContext with an unknown triple is rarely a good idea (as usually
all our ASTs have a valid triple that is either from the host or the target) and the
default argument makes it far to easy to implicitly create such an AST. Let's
remove it and force people to pass a triple.
The only place where we don't pass a triple is a DWARFASTParserClangTests
where we now just pass the host triple instead (the test doesn't depend on any
triple so this shouldn't change anything).
|
|
|
|
|
|
|
| |
ArchSpec has a superset of the information of llvm::Triple but the ClangASTContext
just uses the Triple part of it. This deletes the ArchSpec constructor and all
the code creating ArchSpecs and instead just uses the llvm::Triple constructor
for ClangASTContext.
|
|
|
|
|
|
| |
This constructor is supposed to take a string representing an llvm::Triple.
We might as well take a llvm::Triple here which saves us all the string
conversions in the call sites and we make this more type safe.
|
|
|
|
|
|
|
| |
and delete references to it
There is no clang::Action anymore so our forward decl for it and the obsolete pointer in the
ASTStructExtractor can both go (that code anyway didn't do anything).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QualType
LLDB frequently converts QualType to CompilerType. This is currently done like this:
result = CompilerType(this, qual_type_var.getAsOpaquePtr())
There are a few shortcomings in this current approach:
1. CompilerType's constructor takes a void* pointer so it isn't type safe.
2. We can't add any sanity checks to the CompilerType constructor (e.g. that the type
actually belongs to the passed ClangASTContext) without expanding the TypeSystem API.
3. The logic for converting QualType->CompilerType is spread out over all of LLDB so
changing it is difficult (e.g., what if we want to just pass the type ptr and not the
1type_ptr | qual_flags1 to CompilerType).
This patch adds a `ClangASTContext::GetType` function similar to the other GetTypeForDecl
functions that does this conversion in a type safe way.
It also adds a sanity check for Tag-based types that the type actually belongs to the
current ClangASTContext (Types don't seem to know their ASTContext, so we have to
workaround by looking at the decl for the underlying TagDecl. This doesn't cover all types
we construct but it's better than no sanity check).
|
|
|
|
|
|
|
|
|
| |
variable warning
CompilerType has no virtual functions and no statements in its constructors,
so we can simplify this code. This also allows Clang to emit unused variable warnings
for CompilerType, so I also removed one unused variable that otherwise causes -Werror
builds to fail.
|
|
|
|
| |
Also removes the GetASTContext call from this code.
|
|
|
|
|
|
| |
These functions need a ClangASTContext instance that we would otherwise
recalculate by calling GetASTContext (which is no longer necessary with
this patch).
|
|
|
|
| |
We can always call the member function version of this function.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The enumeration EntryType is used as a bit field of DebugMacroEntry:
```
EntryType m_type : 3
```
Since underlying type of enumeration is implementation-dependent, a signed integer is
converted to the 3-bit value by some compilers (MSVC).
That's why a DebugMacroEntry instance that was created with EntryType value > 3 (END_FILE or INDIRECT)
contains incorrect negative value in its m_type data-member.
|
|
|
|
| |
ClangASTContext::GetBuiltinTypeForDWARFEncodingAndBitSize
|
|
|
|
|
|
|
|
|
| |
class
m_scratch_ast_source_up is only used by ClangASTContextForExpressions so it
should also be declared only in that class. Also make all other members of
ClangASTContext private and move the initialization code for ClangASTContextForExpressions
into the constructor.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ClangExternalASTSourceCommon's purpose is to store a map from
Decl*/Type* to ClangASTMetadata. Usually this data is accessed
via the ClangASTContext interface which then grabs the
current ExternalASTSource of its ASTContext, tries to cast it
to ClangExternalASTSourceCommon and then accesses the metadata
map. If the casting fails the setter does nothing and the getter
returns a nullptr as if there was no known metadata for a type/decl.
This system breaks as soon as any non-LLDB ExternalASTSource is added via
a multiplexer to our existing ExternalASTSource (in which case we suddenly
loose all out metadata as the casting always fails with an ExternalASTSource
that is not inheriting from ClangExternalASTSourceCommon).
This patch moves the metadata map to the ClangASTContext. This gets
rid of all the fragile casting, the requirement that every ExternalASTSource in
LLDB has to inherit from ClangExternalASTSourceCommon and simplifies
the metadata implementation to a simple map lookup. As ClangExternalASTSourceCommon
had no other purpose than storing metadata, this patch deletes this class
and replaces all uses with clang::ExternalASTSource.
No other code changes in this commit beside the AppleObjCDeclVendor which
was the only code that did not use the ClangASTContext interface but directly
accessed the ClangExternalASTSourceCommon.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This class is only used by the ClangASTContext so we might as well
simplify this whole logic by just passing a ClangASTContext instead
of a list of callbacks and a void* pointer. If we ever need this
to support other classes then we can define some interface that
ClangASTContext implements but for now this isn't needed.
I also removed any code for m_callback_find_by_name as this was
always a nullptr in LLDB and removed all overriden implementations
that just redefined the default no-op implementation that the
ExternalASTSource provides.
Also removed the assert.h workarounds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These two functions are just calling their equivalent function
in ASTContext and implicitly convert the result to a
DeclContext* (a parent class of TranslationUnitDecl). This leads
to the absurd situation that we had to cast the result of
GetTranslationUnitDecl to a TranslationUnitDecl*. The only reason
we did this implicit conversion to the parent class
was that the void* conversion for the CompilerDeclContext constructor
was sound (which otherwise would receive a Decl* pointer when
called with a TranslationUnitDecl*).
Now that the CompilerDeclContext constructor is type safe we can
properly implement these functions by actually returning the
right type. Also deletes the static inconvenience method that was
not used anywhere.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CompilerDeclContext constructor takes a void* pointer which
means that all callers of this constructor need to first explicitly
convert all pointers to clang::DeclContext*. This causes that we
for example can't just pass a TranslationUnitDecl* to the constructor without
first casting it to its parent class (as it inherits from both
Decl and DeclContext so the void* pointer is actually a Decl*).
This patch introduces a utility function in the ClangASTContext
which gets rid of the requirement to cast all pointers to
clang::DeclContext. Also moves all constructor calls to use this
function instead which is NFC (beside the change in
DWARFASTParserClangTests.cpp).
|
|
|
|
|
|
| |
The `-r` option for `command script import` is there for legacy
compatibility, however the can_reload flag is always set to true. This
patch removes the flag and any code that relies on it being false.
|
|
|
|
|
| |
Rather than checking for Python explicitly, let the script interpreter
handle things and print an error if the functionality is not supported.
|
| |
|
|
|
|
|
|
| |
- Fix enum entry order.
- Fix missing enum case in CommandObjectBreakpointCommand.
- Add Lua entry to swtich in LanguageToString and simplify the code.
|
|
|
|
|
|
|
|
|
| |
Rather than holding on to one script interpreter, it should be possible
to request a script interpreter for a specific scripting language. The
GetScriptInterpreter method now takes an optional scripting language
argument.
(NFC)
|
|
|
|
|
|
|
|
|
|
|
| |
remove dead nullptr checks
ClangASTContext::getASTContext() currently returns a ptr but we have an assert there since a
while that the ASTContext is not a nullptr. This causes that we still have a lot of code
that is doing nullptr checks on the result of getASTContext() which is all unreachable code.
This patch changes the return value to a reference to make it clear this can't be a nullptr
and deletes all the nullptr checks.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Their naming is misleading as they only return the
ClangASTContext-owned variables. For ClangASTContext instances constructed
for a given clang::ASTContext they silently generated duplicated instances
(e.g., a second IdentifierTable) that were essentially unusable.
This removes all these getters as they are anyway not very useful in comparison
to just calling the clang::ASTContext getters. The initialization
code has been moved to the CreateASTContext initialization method so that all
code for making our own clang::ASTContext is in one place.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements a very elementary Lua script interpreter. It supports
running a single command as well as running interactively. It uses
editline if available. It's still missing a bunch of stuff though. Some
things that I intentionally ingored for now are that I/O isn't properly
hooked up (so every print goes to stdout) and the non-editline support
which is not handling a bunch of corner cases. The latter is a matter of
reusing existing code in the Python interpreter.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html
Differential revision: https://reviews.llvm.org/D71234
|
|
|
|
|
|
|
|
|
| |
Previously, if the current function had a nonstandard stack layout/ABI, and had a valid
data pointer in the location where the return address is usually located, data corruption
would occur when the breakpoint was written. This could lead to an incorrectly reported
crash or silent corruption of the program's state. Now, if the above check fails, the command safely aborts.
Differential Revision: https://reviews.llvm.org/D71372
|
|
|
|
|
|
| |
We already pass a Decl here and the additional ASTContext needs to
match the Decl. We might as well just pass the Decl and then extract
the ASTContext from that.
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the boilerplate necessary to support the Lua script
interpreter. The interpreter is not functional yet and just reports that
it's not implemented.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html
Differential revision: https://reviews.llvm.org/D71232
|
| |
|
| |
|
|
|
|
|
|
|
| |
document it
This function is just setting the layout for the given RecordDecl so
the current name is not very descriptive. Also add some documentation for it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As discussed on the mailing list [1] we have to make a decision for how to proceed with the modern-type-lookup.
This patch removes modern-type-lookup from LLDB. This just removes all the code behind the modern-type-lookup
setting but it does *not* remove any code from Clang (i.e., the ExternalASTMerger and the clang-import-test stay around
for now).
The motivation for this is that I don't think that the current approach of implementing modern-type-lookup
will work out. Especially creating a completely new lookup system behind some setting that is never turned on by anyone
and then one day make one big switch to the new system seems wrong. It doesn't fit into the way LLVM is developed and has
so far made the transition work much more complicated than it has to be.
A lot of the benefits that were supposed to come with the modern-type-lookup are related to having a better organization
in the way types move across LLDB and having less dependencies on unrelated LLDB code. By just looking at the current code (mostly
the ClangASTImporter) I think we can reach the same goals by just incrementally cleaning up, documenting, refactoring
and actually testing the existing code we have.
[1] http://lists.llvm.org/pipermail/lldb-dev/2019-December/015831.html
Reviewers: shafik, martong
Subscribers: rnkovacs, christof, arphaman, JDevlieghere, usaxena95, lldb-commits, friss
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71562
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
evaluator.
Summary:
D69991 introduced `__attribute__((objc_direct))` that allows directly calling methods without message passing.
This patch adds support for calling methods with this attribute to LLDB's expression evaluator.
The patch can be summarised in that LLDB just adds the same attribute to our module AST when we find a
method with `__attribute__((objc_direct))` in our debug information.
Reviewers: aprantl, shafik
Reviewed By: shafik
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71196
|
|
|
|
|
|
|
|
|
| |
If you don't do this you end up running arbitrary code with
only one thread allowed to run, which can cause deadlocks.
<rdar://problem/56422478>
Differential Revision: https://reviews.llvm.org/D71440
|
|
|
|
|
|
|
| |
The overloads that don't take a CompilerType serve no purpose as we
always have a CompilerType in the scope where we call them. Instead
just call the overload that takes a CompilerType and delete the
now unused other overloaded methods.
|
|
|
|
|
|
|
|
|
|
| |
ClangExternalASTSourceCommon.h
Changing metadata of a ClangASTContext currently requires to include
the unrelated ClangExternalASTSourceCommon.h header because it actually defines
the ClangASTMetadata class.
This also removes the dependency from ClangASTImporter to ClangExternalASTSourceCommon.
|
|
|
|
| |
ResolveDeclOrigin was just an inconvenience method around GetDeclOrigin.
|