We try to build a CompilerType from the persistent decls so we need
a ClangASTContext. With this patch the ClangPersistentVariables store
the associated ClangASTContext of the persistent decls (which is
always the scratch ClangASTContext) and no longer call GetASTContext
to map back from clang::ASTContext to ClangASTContext.
Instead of returning NamedDecls and then calling GetASTContext
to find back the ClangASTContext we used can just implement the
FindDecl variant that returns CompilerDecls (and implement the
other function by throwing away the ClangASTContext part of the
compiler decl).
This code actually needs a ClangASTContext but instead takes a
clang::ASTContext and then retrieves the original ClangASTContext
via the global map of ClangASTContexts. Let's change it so
that it takes a ClangASTContext which is simpler and faster.
GetASTContext is really expensive to call as it makes use of the global
mapping from ASTContext to ClangASTContext. This replaces all calls where
we already have the ClangASTContext around and don't need to call
GetASTContext again.
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 function is not very useful, as it's forcing a materialization of
the returned DIEs, and calling it is not substantially simpler than just
iterating over the DIEs manually. Delete it, and rewrite the single
caller.
This bit of code is trying to strip everything up to the first colon
from all debug info paths, as dwarf2 recommends this syntax for storing
the compilation host name. However, this code was too eager, and it
ended up stripping the entire compilation directory, if it did not
contain a forward slash (or a "x:\").
Normally this does not matter, as all absolute paths will contain one of
these patterns, but this does not have to be the case in case the debug
info is produced by "clang -fdebug-compilation-dir", which can end up
producing a relative compilation directory with no slashes (this is one
of the techniques for producing "relocatable" debug info).
This adds a check that the ClangASTContext actually fits to the
DeclContext that we want to create a CompilerDeclContext for. If
the ClangASTContext (and its associated ASTContext) does not fit
to the DeclContext (that is, the DeclContext wasn't created by the
ASTContext), all computations using this malformed CompilerDeclContext
will yield unpredictable results.
Also fixes the only place that actually hits this assert which is the
construction of a CompilerDeclContext in ClangExpressionDeclMap
where we pass an unrelated ASTContext instead of the ASTContext
of the current expression.
I had to revert my previous change to DWARFASTParserClangTests.cpp
back to using the unsafe direct construction of CompilerDeclContext
as this assert won't work if the DeclContext we pass isn't a valid
DeclContext in the first place.
Summary:
This code is handling debug info paths starting with /proc/self/cwd,
which is one of the mechanisms people use to obtain "relocatable" debug
info (the idea being that one starts the debugger with an appropriate
cwd and things "just work").
Instead of resolving the symlinks inside DWARFUnit, we can do the same
thing more elegantly by hooking into the existing Module path remapping
code. Since llvm::DWARFUnit does not support any similar functionality,
doing things this way is also a step towards unifying llvm and lldb
dwarf parsers.
Reviewers: JDevlieghere, aprantl, clayborg, jdoerfert
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71770
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.
Don't create a new lua state on every operation. Share a single state
across the lifetime of the script interpreter. Add simple locking to
prevent two threads from modifying the state concurrently.
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.
echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()'
Actual:
error: Expression can't be run, because there is no JIT compiled function
Expected:
<nothing, sync() has been executed>
This patch has been checked by:
D71707: clang-tidy: new bugprone-pointer-cast-widening
https://reviews.llvm.org/D71707
Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended:
echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long
long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out
<stdin>: In function ‘main’:
<stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000
With debug output:
Actual:
IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3)
Code can be run in the target.
Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff
Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv
Sections:
[0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text)
...
HandleCommand, command did not succeed
error: Expression can't be run, because there is no JIT compiled function
Expected:
IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3)
IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060].
Code can be run in the target.
Found function, has local address 0xb6fac000 and remote address 0xb6ff9020
Function's code range is [0xb6ff9020+0x40]
...
Function data has contents:
0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1
...
Function disassembly:
0xb6ff9020: 0xe92d4c10 push {r4, r10, r11, lr}
Differential revision: https://reviews.llvm.org/D71498
This is a purely cosmetic change that is NFC in terms of the binary
output. I bugs me that I called the attribute DW_AT_LLVM_isysroot
since the "i" is an artifact of GCC command line option syntax
(-isysroot is in the category of -i options) and doesn't carry any
useful information otherwise.
This attribute only appears in Clang module debug info.
Differential Revision: https://reviews.llvm.org/D71722
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
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.
Summary:
Fixes PR41237 - SIGSEGV on call expression evaluation when debugging clang
When linking multiple compilation units that define the same functions,
the functions is merged but their debug info is not. This ignores debug
info entries for functions in a non-executable sections; those are
functions that were definitely dropped by the linker.
Reviewers: spyffe, clayborg, jasonmolenda
Reviewed By: clayborg
Subscribers: labath, aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71487
This error message didn't specify which file was malformed, so
there's some hunting-around required if it comes up. We have the
filename; include it in the error message.
Remove the hack that populates the cpsr register in the gpr struct by
writing past the end of the array. This was tripping up ASan.
Patch by: Reva Cuthbertson
This adds a unit test for looking up persistent declarations in the scratch AST
context. Also adds the `GetPersistentDecl` hook to the ClangExpressionDeclMap
that this unit test can emulate looking up persistent variables without having
a lldb_private::Target.
The ClangExpressionDeclMap should be testable from a unit test. This is currently
impossible as they have both dependencies on Target/ExecutionContext from their
constructor. This patch allows constructing these classes without an active Target
and adds the missing tests for running without a target that we can do at least
a basic lookup test without crashing.
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
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
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.
Summary:
Right now, NSException::GetSummary() has the following output:
"name: $exception_name - reason: $exception_reason"
It would be better to simplify the output by removing the name and only
showing the exception's reason. This way, annotations would look nicer in
the editor, and would be a shorter summary in the Variables Inspector.
Accessing the exception's name can still be done by expanding the
NSException object in the Variables Inspector.
rdar://54770115
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71311
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Summary:
LLDB associates additional information with Types and Declarations which it calls ClangASTMetadata.
ClangASTMetadata is stored by the ClangASTSourceCommon which is implemented by having a large map of
`void *` keys to associated `ClangASTMetadata` values. To make this whole mechanism even unsafer
we also decided to use `clang::Decl *` as one of pointers we throw in there (beside `clang::Type *`).
The Decl class hierarchy uses multiple inheritance which means that not all pointers have the
same address when they are implicitly converted to pointers of their parent classes. For example
`clang::Decl *` and `clang::DeclContext *` won't end up being the same address when they
are implicitly converted from one of the many Decl-subclasses that inherit from both.
As we use the addresses as the keys in our Metadata map, this means that any implicit type
conversions to parent classes (or anything else that changes the addresses) will break our metadata tracking
in obscure ways.
Just to illustrate how broken this whole mechanism currently is:
```lang=cpp
// m_ast is our ClangASTContext. Let's double check that from GetTranslationUnitDecl
// in ClangASTContext and ASTContext return the same thing (one method just calls the other).
assert(m_ast->GetTranslationUnitDecl() == m_ast->getASTContext()->getTranslationUnitDecl());
// Ok, both methods have the same TU*. Let's store metadata with the result of one method call.
m_ast->SetMetadataAsUserID(m_ast->GetTranslationUnitDecl(), 1234U);
// Retrieve the same Metadata for the TU by using the TU* from the other method... which fails?
EXPECT_EQ(m_ast->GetMetadata(m_ast->getASTContext()->getTranslationUnitDecl())->GetUserID(), 1234U);
// Turns out that getTranslationUnitDecl one time returns a TranslationUnitDecl* but the other time
// we return one of the parent classes of TranslationUnitDecl (DeclContext).
```
This patch splits up the `void *` API into two where one does the `clang::Type *` tracking and one the `clang::Decl *` mapping.
Type and Decl are disjoint class hierarchies so there is no implicit conversion possible that could influence
the address values.
I had to change the storing of `clang::QualType` opaque pointers to their `clang::Type *` equivalents as
opaque pointers are already `void *` pointers to begin with. We don't seem to ever set any qualifier in any of these
QualTypes to this conversion should be NFC.
Reviewers: labath, shafik, aprantl
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71409
Target doesn't really need to know about ClangASTContext more than any
other TypeSystem. We can create a method ClangASTContext::GetScratch for
anything who needs a ClangASTContext specifically instead of just a
generic TypeSystem.
Summary: Not once have I looked at these numbers in a log and considered them useful. Also this should not have been implemented via an unguarded list of globals.
Reviewers: martong, shafik
Reviewed By: shafik
Subscribers: rnkovacs, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71336
I don't think this test case can be handled correctly on AAPCS64.
The ABI says that the caller passes the address of the return object
in x8. x8 is a caller-spilled (aka "volatile") register, and the
function is not required to preserve x8 or to copy the address back
into x8 on function exit like the SysV x86_64 ABI does with rax.
(from aapcs64: "there is no requirement for the callee to preserve the
value stored in x8")
From my quick reading of ABISysV_arm64, I worry that it may actually be
using the value in x8 at function exit, assuming it still has the
address of the return object -
if (is_return_value) {
// We are assuming we are decoding this immediately after returning from
// a function call and that the address of the structure is in x8
reg_info = reg_ctx->GetRegisterInfoByName("x8", 0);
This will work on trivial test programs / examples, but if the function
does another function call, or overwrites x8 as a scratch register, lldb
will provide incorrect values to the user.
ABIMacOSX_arm64 doesn't do this, but it also doesn't flag the value
as unavailable so we're providing incorrect values to the user all
the time. I expect my fix will be to make ABIMacOSX_arm64 flag
the return value as unretrievable, unless I've misread the ABI.
Summary:
This adds support for DWARF5 location lists which are specified
indirectly, via an index into the debug_loclists offset table. This
includes parsing the DW_AT_loclists_base attribute which determines the
location of this offset table, and support for new form DW_FORM_loclistx
which is used in conjuction with DW_AT_location to refer to the location
lists in this way.
The code uses the llvm class to parse the offset information, and I've
also tried to structure it similarly to how the relevant llvm
functionality works.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71268
As suggested by Pavel in a code review:
> Can we replace this (and maybe python too, while at it) with a
> Host/Config.h entry? A global definition means that one has to
> recompile everything when these change in any way, whereas in
> practice only a handful of files need this..
Differential revision: https://reviews.llvm.org/D71280
When running the test suite with always capture on, a handful of tests
are failing because they have multiple targets and therefore multiple
GDB remote connections. The current reproducer infrastructure is capable
of dealing with that.
This patch reworks the GDB remote provider to support multiple GDB
remote connections, similar to how the reproducers support shadowing
multiple command interpreter inputs. The provider now keeps a list of
packet recorders which deal with a single GDB remote connection. During
replay we rely on the order of creation to match the number of packets
to the GDB remote connection.
Differential revision: https://reviews.llvm.org/D71105
If not set, the address byte size was implied to be the one of the
host process.
This allows reverting the functional change from 31087b2ae9154, since
now PECOFF does the same as ELF and MachO wrt setting both byte order
and address size on m_data within ParseHeader.
Differential Revision: https://reviews.llvm.org/D71108
Summary:
Lldb support base address selection entries in location lists was broken
for a long time. This wasn't noticed until llvm started producing these
kinds of entries more frequently with r374600.
In r374769, I made a quick patch which added sufficient support for them
to get the test suite to pass. However, I did not fully understand how
this code operates, and so the fix was not complete. Specifically, what
was lacking was the ability to handle modules which were not loaded at
their preferred load address (for instance, due to ASLR).
Now that I better understand how this code works, I've come to the
conclusion that the current setup does not provide enough information
to correctly process these entries. In the current setup the location
lists were parameterized by two addresses:
- the distance of the function start from the start of the compile unit.
The purpose of this was to make the location ranges relative to the
start of the function.
- the actual address where the function was loaded at. With this the
function-start-relative ranges can be translated to actual memory
locations.
The reason for the two values, instead of just one (the load bias) is (I
think) MachO, where the debug info in the object files will appear to be
relative to the address zero, but the actual code it refers to
can be moved and reordered by the linker. This means that the location
lists need to be "linked" to reflect the locations in the actual linked
file.
These two bits of information were enough to correctly process location
lists which do not contain base address selection entries (and so all
entries are relative to the CU base). However, they don't work with
them because, in theory two base address can be completely unrelated (as
can happen for instace with hot/cold function splitting, where the
linker can reorder the two pars arbitrarily).
To fix that, I split the first parameter into two:
- the compile unit base address
- the function start address, as is known in the object file
The new algorithm becomes:
- the location lists are processed as they were meant to be processed.
The CU base address is used as the initial base address value. Base
address selection entries can set a new base.
- the difference between the "file" and "load" function start addresses
is used to compute the load bias. This value is added to the final
ranges to get the actual memory location.
This algorithm is correct for non-MachO debug info, as there the
location lists correctly describe the code in the final executable, and
the dynamic linker can just move the entire module, not pieces of it. It
will also be correct for MachO if the static linker preserves relative
positions of the various parts of the location lists -- I don't know
whether it actually does that, but judging by the lack of base address
selection support in dsymutil and lldb, this isn't something that has
come up in the past.
I add a test case which simulates the ASLR scenario and demonstrates
that base address selection entries now work correctly here.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: dblaikie, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70532
Summary:
This patch adds support for atomic types (DW_TAG_atomic_type) to LLDB. It's mostly just filling out all the switch-statements that didn't implement Atomic case with the usual boilerplate.
Thanks Pavel for writing the test case.
Reviewers: labath, aprantl, shafik
Reviewed By: labath
Subscribers: jfb, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71183
Summary:
This patch simplifies register accesses in NativeRegisterContextLinux_arm64
and also adds some bare minimum caching to avoid multiple calls to ptrace
during a stop.
Linux ptrace returns data in the form of structures containing GPR/FPR data.
This means that one single call is enough to read all GPRs or FPRs. We do
that once per stop and keep reading from or writing to the buffer that we
have in NativeRegisterContextLinux_arm64 class. Before a resume or detach we
write all buffers back.
This is tested on aarch64 thunder x1 with Ubuntu 18.04. Also tested
regressions on x86_64.
Reviewers: labath, clayborg
Reviewed By: labath
Subscribers: kristof.beyls, lldb-commits
Differential Revision: https://reviews.llvm.org/D69371
In DWARF5 DW_AT_low_pc (and DW_AT_entry_pc, and possibly others) can use
DW_FORM_addrx to refer to the address indirectly. This means we need to
have processed the DW_AT_addr_base attribute before we can do anything
with these.
Since we were processing the unit attributes serially, this created a
problem in cases where the DW_AT_addr_base comes after DW_AT_low_pc --
we would end up computing the wrong unit base address, which also
corrupted any values which later depended on that (for instance range
lists). Clang currently always emits DW_AT_addr_base last.
The fix is simple -- process DW_AT_addr_base first, regardless of its
position in the attribute list.
the value of DW_AT_rnglists_base of the skeleton unit is for that unit
alone (e.g. used in DW_AT_ranges of the unit DIE) and should not apply
to the split unit.
The split unit has a hardcoded range list base value -- we should
initialize range list code whenever we detect a nonempty
debug_rnglists.dwo section.
Summary:
Yet another step on the long road towards getting rid of lldb's Stream class.
We probably should just make this some kind of member of Address/AddressRange, but it seems quite often we just push
in random integers in there and this is just about getting rid of Stream and not improving arbitrary APIs.
I had to rename another `DumpAddress` function in FormatEntity that is dumping the content of an address to make Clang happy.
Reviewers: labath
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71052
Summary:
Our rnglist support was working only for the trivial cases (one CU),
because we only ever parsed one contribution out of the debug_rnglists
section. This means we were never able to resolve range lists for the
second and subsequent units (DW_FORM_sec_offset references came out
blang, and DW_FORM_rnglistx references always used the ranges lists from
the first unit).
Since both llvm and lldb rnglist parsers are sufficiently
self-contained, and operate similarly, we can fix this problem by
switching to the llvm parser instead. Besides the changes which are due
to variations in the interface, the main thing is that now the range
list object is a member of the DWARFUnit, instead of the entire symbol
file. This ensures that each unit can get it's own private set of range
list indices, and is consistent with how llvm's DWARFUnit does it
(overall, I've tried to structure the code the same way as the llvm
version).
I've also added a test case for the two unit scenario.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: dblaikie, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71021
Summary:
This patch adds code which will substitute references to the full object
constructors/destructors with their base object versions.
Like all substitutions in this category, this operation is not really
sound, but doing this in a more precise way allows us to get rid of a
much larger hack -- matching function according to their demangled
names, which effectively does the same thing, but also much more.
This is a (very late) follow-up to D54074.
Background: clang has an optimization which can eliminate full object
structors completely, if they are found to be equivalent to their base
object versions. It does this because it assumes they can be regenerated
on demand in the compile unit that needs them (e.g., because they are
declared inline). However, this doesn't work for the debugging scenario,
where we don't have the structor bodies available -- we pretend all
constructors are defined out-of-line as far as clang is concerned. This
causes clang to emit references to the (nonexisting) full object
structors during expression evaluation.
Fun fact: This is not a problem on darwin, because the relevant
optimization is disabled to work around a linker bug.
Reviewers: teemperor, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70721
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
Summary:
The FileSpec class is often used as a sort of a pattern -- one specifies
a bare file name to search, and we check if in matches the full file
name of an existing module (for example).
These comparisons used FileSpec::Equal, which had some support for it
(via the full=false argument), but it was not a good fit for this job.
For one, it did a symmetric comparison, which makes sense for a function
called "equal", but not for typical searches (when searching for
"/foo/bar.so", we don't want to find a module whose name is just
"bar.so"). This resulted in patterns like:
if (FileSpec::Equal(pattern, file, pattern.GetDirectory()))
which would request a "full" match only if the pattern really contained
a directory. This worked, but the intended behavior was very unobvious.
On top of that, a lot of the code wanted to handle the case of an
"empty" pattern, and treat it as matching everything. This resulted in
conditions like:
if (pattern && !FileSpec::Equal(pattern, file, pattern.GetDirectory())
which are nearly impossible to decipher.
This patch introduces a FileSpec::Match function, which does exactly
what most of FileSpec::Equal callers want, an asymmetric match between a
"pattern" FileSpec and a an actual FileSpec. Empty paterns match
everything, filename-only patterns match only the filename component.
I've tried to update all callers of FileSpec::Equal to use a simpler
interface. Those that hardcoded full=true have been changed to use
operator==. Those passing full=pattern.GetDirectory() have been changed
to use FileSpec::Match.
There was also a handful of places which hardcoded full=false. I've
changed these to use FileSpec::Match too. This is a slight change in
semantics, but it does not look like that was ever intended, and it was
more likely a result of a misunderstanding of the "proper" way to use
FileSpec::Equal.
[In an ideal world a "FileSpec" and a "FileSpec pattern" would be two
different types, but given how widespread FileSpec is, it is unlikely
we'll get there in one go. This at least provides a good starting point
by centralizing all matching behavior.]
Reviewers: teemperor, JDevlieghere, jdoerfert
Subscribers: emaste, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70851
ParseChildMembers does a few things, only one part is actually parsing a single
member. This extracts the member parsing logic into its own function.
This commit just moves the code as-is into its own function and forwards the parameters/
local variables to it, which means it should be NFC.
The only actual changes to the code are replacing 'break's (and one very curious 'continue'
that behaves like a 'break') with 'return's.
This code was just creating a new SymbolContextList with any found functions
in the front and orders them by how close they are to the current frame.
This refactors this code into its own function to make this more obvious.
Doesn't do any other changes to the code, so this is NFC.
Summary:
Previously the ABI plugin exposed some "register infos" and the
gdb-remote code used those to fill in the missing bits. Now, the
"filling in" code is in the ABI plugin itself, and the gdb-remote code
just invokes that.
The motivation for this is two-fold:
a) the "augmentation" logic is useful outside of process gdb-remote. For
instance, it would allow us to avoid repeating the register number
definitions in minidump code.
b) It gives more implementation freedom to the ABI classes. Now that
these "register infos" are essentially implementation details, classes
can use other methods to obtain dwarf/eh_frame register numbers -- for
instance they can consult llvm MC layer.
Since the augmentation code was not currently tested anywhere, I took
the opportunity to create a simple test for it.
Reviewers: jasonmolenda, clayborg, tatyana-krasnukha
Subscribers: aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70906
Extend EmulateMOVRdRm to identify "mov r11, sp" in thumb mode as
setting the frame pointer, if r11 is the frame pointer register.
Differential Revision: https://reviews.llvm.org/D70797
ClangASTSource currently takes a clang::ASTContext and keeps that
around, but a lot of LLDB's functionality for doing operations
on a clang::ASTContext is in its ClangASTContext twin class. We
currently constantly recompute the respective ClangASTContext
from the clang::ASTContext while we instead could just pass and
store a ClangASTContext in the ClangASTSource. This also allows
us to get rid of a bunch of unreachable error checking for cases
where recomputation fails for some reason.
This code is behind a `if (log)` that is always a nullptr as the initializer
was commented out. One could uncomment the initializer code, but then this logging
code just leads to a deadlock as it tries to aquire the module lock.
This removes the logging code until I get this working again.
Summary:
CompileUnit is a complicated class. Having it be implicitly convertible
to a FileSpec makes reasoning about it even harder.
This patch replaces the inheritance by a simple member and an accessor
function. This avoid the need for casting in places where one needed to
force a CompileUnit to be treated as a FileSpec, and does not add much
verbosity elsewhere.
It also fixes a bug where we were wrongly comparing CompileUnit& and a
CompileUnit*, which compiled due to a combination of this inheritance
and the FileSpec*->FileSpec implicit constructor.
Reviewers: teemperor, JDevlieghere, jdoerfert
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70827
COFF section names can either be stored truncated to 8 chars, in the
section header, or as a longer section name, stored separately in the
string table.
libunwind locates the .eh_frame section by runtime introspection,
which only works for section names stored in the section header (as
the string table isn't mapped at runtime). To support this behaviour,
lld always truncates the section names for sections that will be
mapped, like .eh_frame.
Differential Revision: https://reviews.llvm.org/D70745
InitializeContext is useful for allocating a (potentially variable
size) CONTEXT struct in an unaligned byte buffer. In this case, we
already have a fixed size CONTEXT we want to initialize, and we only
used this as a very roundabout way of zero initializing it.
Instead just memset the CONTEXT we have, and set the ContextFlags field
manually.
This matches how it is done in NativeRegisterContextWindows_*.cpp.
This also makes LLDB run successfully in Wine (for a trivial tested
case at least), as Wine hasn't implemented the InitializeContext
function.
Differential Revision: https://reviews.llvm.org/D70742
This way it looks more like the code around it. The assert is also gone as it just
checks that the variables we declare directly above were not initialized by anyone.
That made more sense when this was one large function.
Part of the work to split up this monolithic parsing function.
Should be NFC but due to the kafkaesque control flow in this case statement this might
have some unintended side effects.
Fix handling concurrent watchpoint events so that they are reported
correctly in LLDB.
If multiple watchpoints are hit concurrently, the NetBSD kernel reports
them as series of SIGTRAPs with a thread specified, and the debugger
investigates DR6 in order to establish which watchpoint was hit. This
is normally fine.
However, LLDB disables and reenables the watchpoint on all threads after
each hit, which results in the hit status from DR6 being wiped.
As a result, it can't establish which watchpoint was hit in successive
SIGTRAP processing.
In order to workaround this problem, clear DR6 only if the breakpoint
is overwritten with a new one. More specifically, move cleaning DR6
from ClearHardwareWatchpoint() to SetHardwareWatchpointWithIndex(),
and do that only if the newly requested watchpoint is different
from the one being set previously. This ensures that the disable-enable
logic of LLDB does not clear watchpoint hit status for the remaining
threads.
This also involves refactoring of watchpoint logic. With the old logic,
clearing watchpoint involved wiping dr6 & dr7, and setting it setting
dr{0..3} & dr7. With the new logic, only enable bit is cleared
from dr7, and the remaining bits are cleared/overwritten while setting
new watchpoint.
Differential Revision: https://reviews.llvm.org/D70025
NetBSD ptrace interface does not populate watchpoints to newly-created
threads. Solve this via copying the watchpoints from the current thread
when new thread is reported via TRAP_LWP.
Add a test that verifies that when the user does not have permissions
to set watchpoints on NetBSD, the 'watchpoint set' errors out gracefully
and thread monitoring does not crash on being unable to copy watchpoints
to new threads.
Differential Revision: https://reviews.llvm.org/D70023
Implement major improvements to multithreaded program support. Notably,
support tracking new and exited threads, associate signals and events
with correct threads and support controlling individual threads when
resuming.
Firstly, use PT_SET_EVENT_MASK to enable reporting of created and exited
threads via SIGTRAP. Handle TRAP_LWP events to keep track
of the currently running threads.
Secondly, update the signal (both generic and SIGTRAP) handling code
to account for per-thread signals correctly. Signals delivered
to the whole process are reported on all threads, while per-thread
signals and events are reported only to the specific thread.
The remaining threads are marked as 'stopped with no reason'. Note that
NetBSD always stops all threads on debugger events.
Thirdly, implement the ability to set every thread as running, stopped
or single-stepping separately while continuing the process. This also
provides the ability to send a signal to the whole process or to one
of its thread while resuming.
Differential Revision: https://reviews.llvm.org/D70022
Summary:
Adds support for doing range-based for-loops on LLDB's VariableList and
modernises all the index-based for-loops in LLDB where possible.
Reviewers: labath, jdoerfert
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70668
Summary:
LLDB's ASTDumper is just a clone of Clang's ASTDumper but with some scary code and
some unrelated functionality (like dumping name/attributes of types). This removes LLDB's ASTDumper
and replaces its uses with the `ClangUtils::DumpDecl` method that just calls Clang's ASTDumper
and returns the result as a string.
The few uses where we just want a textual representation of a type (which will print their name/attributes but not
dump any AST) are now also in ClangUtil under a `ToString` name until we find a better home for them.
Reviewers: labath
Reviewed By: labath
Subscribers: mgorny, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70663
Split CallEdge into DirectCallEdge and IndirectCallEdge. Teach
DWARFExpression how to evaluate entry values in cases where the current
activation was created by an indirect call.
rdar://57094085
Differential Revision: https://reviews.llvm.org/D70100
This affects -gmodules only.
Under normal operation pcm_type is a shallow forward declaration
that gets completed later. This is necessary to support cyclic
data structures. If, however, pcm_type is already complete (for
example, because it was loaded for a different target before),
the definition needs to be imported right away, too.
Type::ResolveClangType() effectively ignores the ResolveState
inside type_sp and only looks at IsDefined(), so it never calls
ClangASTImporter::ASTImporterDelegate::ImportDefinitionTo(),
which does extra work for Objective-C classes. This would result
in only the forward declaration to be visible.
An alternative implementation would be to sink this into Type::ResolveClangType ( 88235812a7/lldb/source/Symbol/Type.cpp (L5809)) though it isn't clear to me how to best do this from a layering perspective.
rdar://problem/52134074
Differential Revision: https://reviews.llvm.org/D70415
lldb would silently accept a response to the 'g' packet
(read all registers) which was too large; this handles the
case where it is too small.
Differential Revision: https://reviews.llvm.org/D70417
<rdar://problem/34916465>
Remove hardcoded string prefix length assumption causing issues when
concatenating summary for NSURL in NSURLSummaryProvider. Provider relies
on concatenation of NSStringProvider results for summary, and while the
strings are prefixed with '@' in Objective-C, that is not the case in
Swift causing part of the description to be truncated.
This will be tested in the downstream fork.
Patch by Martin Svensson!
Searching persistent decls is a small subset of the things
FindExternalVisibleDecls does. It should be its own function instead
of being encapsulated in this `do { } while(false);` pattern.
This overload is only used in one place and having static overloads for
all methods that only do an additional clang::ASTContext -> ClangASTContext
conversion is just not sustainable.
Summary:
This is some really shady code. It's supposed to kick in after an expression already failed and then try to look
up "unknown types" that for some undocumented reason can't be resolved during/before parsing. Beside the
fact that we never mark any type as `EVUnknownType` in either swift-lldb or lldb (which means this code is unreachable),
this code doesn't even make the expression evaluation succeed if if would ever be executed but instead seems
to try to load more debug info that maybe any following expression evaluations might succeed.
This patch removes ClangExpressionDeclMap::ResolveUnknownTypes and the related data structures/checks/calls.
Reviewers: davide
Reviewed By: davide
Subscribers: aprantl, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70388
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.
Implement thread name getting sysctl() on NetBSD. Also fix
the incorrect type in pthread_setname_np() in the relevant test.
Differential Revision: https://reviews.llvm.org/D70363
Builtins are rarely if ever accessed via the Preprocessor. They are
typically found on the ASTContext, so there should be no performance
penalty to using a pointer indirection to store the builtin context.
Three uses of try_lock intentionally ignore the result, as explained in
the comment. Make that explicit with a void cast.
Add what appears to be a missing return in the clang expression parser
code. It's a functional change, but presumably the right one.
Differential Revision: https://reviews.llvm.org/D70281
This feature is mostly there to aid debugging of Clang module issues,
since the only useful actual the end-user can to is to recompile their
program.
Differential Revision: https://reviews.llvm.org/D70272
I wanted to further simplify ParseTypeFromClangModule by replacing the
hand-rolled loop with ForEachExternalModule, and then realized that
ForEachExternalModule also had the problem of visiting the same leaf
node an exponential number of times in the worst-case. This adds a set
of searched_symbol_files set to the function as well as the ability to
early-exit from it.
Differential Revision: https://reviews.llvm.org/D70215
The test was failing due to a bug in SymbolFileDWARF::FindFunctions --
the function was searching the main dwarf unit for DW_TAG_subprograms,
but the main unit is empty in case of split dwarf. The fix is simple --
search the non-skeleton unit instead.
This bug went unnoticed because this function is expensive, and so one
generally avoids calling it.
Summary:
Clang's raw Lexer doesn't produce any tokens for trailing backslashes in a line. This doesn't work with
LLDB's Clang highlighter which builds the source code to display from the list of tokens the Lexer returns.
This causes that lines with trailing backslashes are lacking the backslash and the following newline when
rendering source code in LLDB.
This patch removes the trailing newline from the current line we are highlighting. This way Clang doesn't
drop the backslash token and we just restore the newline after tokenising.
Fixes rdar://57091487
Reviewers: JDevlieghere, labath
Reviewed By: JDevlieghere, labath
Subscribers: labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70177
This avoids confusing them with fission-related functionality.
I also moved two accessor functions from DWARFDIE into static
functions in DWARFASTParserClang were their only use is located.
Performance issues lead to the libc++ std::function formatter to be disabled. We addressed some of those performance issues by adding caching see D67111
This PR fixes the first lookup performance by not using FindSymbolsMatchingRegExAndType(...) and instead finding the compilation unit the std::function wrapped callable should be in and then searching for the callable directly in the CU.
Differential Revision: https://reviews.llvm.org/D69913
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
Summary:
swift-lldb currently has to patch the ExpressionKind enum to add support for Swift expressions. If we implement LLVM's RTTI
with a static ID variable instead of a centralised enum we can drop that patch.
Reviewers: labath, davide
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #upstreaming_lldb_s_downstream_patches, #lldb
Differential Revision: https://reviews.llvm.org/D70070
We call IsPossibleDynamicType but we also need to check if this is a Clang type,
otherwise other languages with dynamic types (like Swift) might end up being interpreted
as potential Obj-C dynamic types.
When we switched to the LLVM .debug_line parser, the .dSYM-style path
remapping logic stopped working for relative paths because of how
RemapSourceFile silently fails for relative paths. This patch both
makes the code more readable and fixes this particular bug.
One interesting thing I learned is that Module::RemapSourceFile() is a
macOS-only code path that operates on on the lldb::Module level and is
completely separate from target.source-map, which operates on a
per-Target level.
Differential Revision: https://reviews.llvm.org/D70037
rdar://problem/56924558
until we can automatically fall back to p/P if g/G are not supported;
it looks like there is a bug in debugserver's g/G packets taht needs
to be fixed, or debugserver should stop supporting g/G until that bug
is fixed. But we need lldb to be able to fall back to p/P correctly
for that to be a viable workaround.
so we only call ModulesDidLoad at the end of the method
after the new module has been added to the target and
the sections have all been adjusted to their actual
load addresses. Solves a problem where an operating
system plugin in the kernel could be loaded multiple
times; the first before the binary had even been
added to the target.
<rdar://problem/50523558>
While investigating an issue where a different packet was sent during
replay I noticed how annoying it is that the existing assert doesn't
specify what packet is actually different. It's printed to the log, but
enabling logging has the potential to change LLDB's behavior. The same
is true when debugging LLDB while it's replaying the reproducer.
I replaced the assert with a printf of the unexpected packet followed by
a fatal_error wrapped in ifndef NDEBUG. The behavior is the same as the
previous assert, just with more/better context.
Following up on https://reviews.llvm.org/D62221, this change introduces
the settings plugin.process.gdb-remote.use-g-packet-for-reading. When
they are on, 'g' packets are used for reading registers.
Using 'g' packets can improve performance by reducing the number of
packets exchanged between client and server when a large number of
registers needs to be fetched.
Differential revision: https://reviews.llvm.org/D62931
Performance issues lead to the libc++ std::function formatter to be disabled.
This change is the first of two changes that should address the performance issues and allow us to enable the formatter again.
In some cases we end up scanning the symbol table for the callable wrapped by std::function for those cases we will now cache the results and used the cache in subsequent look-ups. This still leaves a large cost for the initial lookup which will be addressed in the next change.
Differential Revision: https://reviews.llvm.org/D67111
Restrict building the readline override to Linux only. It both does not
build on *BSD systems, and is largely irrelevant since they default to
using libedit over readline anyway. This restores the behavior
of the old readline override that also was built only on Linux.
Differential Revision: https://reviews.llvm.org/D69846
Fix https://bugs.llvm.org/show_bug.cgi?id=43830 while avoiding polluting the
global Python namespace.
This both reverts r357277 to rebundle a version of Python's readline module
based on libedit.
However, this patch also provides two improvements over the previous
implementation:
1. use PyMem_RawMalloc instead of PyMem_Malloc, as expected by PyOS_Readline
(prevents to segfault upon exit of interactive session)
2. patch the readline module upon embedded interpreter loading, instead of
patching it globally, which should prevent any side effect on other
modules/packages
3. only activate the patched module if libedit is actually linked in lldb
Differential Revision: https://reviews.llvm.org/D69793
Summary:
This patch updates the last user of ArgInfo::count and deletes
it. I also delete `GetNumInitArguments()` and `GetInitArgInfo()`.
Classess are callables and `GetArgInfo()` should work on them.
On python 3 it already works, of course. `inspect` is good.
On python 2 we have to add yet another special case. But hey if
python 2 wasn't crufty we wouln't need python 3.
I also delete `is_bound_method` becuase it is unused.
This path is tested in `TestStepScripted.py`
Reviewers: labath, mgorny, JDevlieghere
Reviewed By: labath, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69742
Add info for all register sets supported in NetBSD, particularly for all
registers 'expected' by LLDB. This is necessary in order to fix
python_api/lldbutil/iter/TestRegistersIterator.py test that currently
fails due to missing names of register sets (None).
This copies fpreg descriptions from Linux, and combines Linux' AVX
and MPX registers into a single XState group, to fit NetBSD register
group design. Technically, we do not support MPX registers
at the moment but gdb-remote insists on passing their errors anyway,
and if we do not include it in any group, they end up in a separate
anonymous group that breaks the test.
While at it, swap the enums for XState and DBRegs to match register set
ordering.
This also adds a few consts to the lldb-x86-register-enums.h to provide
more consistency between user registers and debug registers.
Differential Revision: https://reviews.llvm.org/D69667
Summary:
This function is only used internally by ClangExpressionParser. By putting it in the ExpressionParser class all languages
that implement ExpressionParser::Parse have to share the same signature (which forces us in downstream to add
swift-specific arguments to ExpressionParser::Parse which then propagate to ClangExpressionParser and so on).
Reviewers: davide
Subscribers: JDevlieghere, lldb-commits
Tags: #upstreaming_lldb_s_downstream_patches, #lldb
Differential Revision: https://reviews.llvm.org/D69710
Summary:
Motivated by Swift using the materializer in a few places which requires us to add this getter ourselves.
We also need a setter, but let's keep this minimal to unblock the downstream reverts in Swift.
Reviewers: davide
Reviewed By: davide
Subscribers: abidh, JDevlieghere, lldb-commits
Tags: #upstreaming_lldb_s_downstream_patches, #lldb
Differential Revision: https://reviews.llvm.org/D69714
Normally you shouldn't be able to have a process with an ItaniumABI plugin
that doesn't have this symbol. But if the loader crashes before loading
libc++abi.dylib (on MacOS), then the symbol might not be present. So we
should check before accessing the pointer.
There isn't a good way to write a test for this, but the change is obvious.
Summary:
Not all minidumps contain information about memory permissions. However,
it is still important to know which regions of memory contain
potentially executable code. This is particularly important for
unwinding on win32, as the default unwind method there relies on
scanning the stack for things which "look like" code pointers.
This patch enables ProcessMinidump to reconstruct the likely permissions
of memory regions using the sections of loaded object files. It only
does this if we don't have a better source (memory info list stream, or
linux /proc/maps) for this information, and only if the information in
the object files does not conflict with the information in the minidump.
Theoretically that last bit could be improved, since the permissions
obtained from the MemoryList streams is also only a very rough guess,
but it did not seem worthwhile to complicate the implementation because
of that because there will generally be no overlap in practice as the
MemoryList will contain the stack contents and not any module data.
The patch adds a test checking that the module section permissions are
entered into the memory region list, and also a test which demonstrate
that now the unwinder is able to correctly find return addresses even in
minidumps without memory info list streams.
There's one TODO left in this patch, which is that the "memory region"
output does not give any indication about the "don't know" values of
memory region permissions (it just prints them as if they permission bit
was set). I address this in a follow up.
Reviewers: amccarth, clayborg
Subscribers: mgrang, lldb-commits
Differential Revision: https://reviews.llvm.org/D69105
Summary:
This change increases the offset of MPX registers (by 128) so they
do not overlap with the offset associated with AVX registers. That was
causing MPX data in GDBRemoteRegisterContext::m_reg_data to get overwritten.
Reviewers: labath
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68874
This can e.g. happen if the debugged executable exits before the initial
stop, e.g. if it fails to load dependent DLLs.
Add a virtual destructor to ProcessDebugger and let it clean up the
session, and make ProcessWindows::OnExitProcess call
ProcessDebugger::OnExitProcess for shared parts.
Fix suggestion by Adrian McCarthy.
Differential Revision: https://reviews.llvm.org/D69503
llvm::object::createBinary returns an Expected<>, which requires
not only checking the object for success, but also requires consuming
the Error, if one was set.
Use LLDB_LOG_ERROR for this case, and change an existing similar log
statement to use it as well, to make sure the Error is consumed even
if the log channel is disabled.
Differential Revision: https://reviews.llvm.org/D69646
Contrary to WoW64 on x86_64, there's no struct similar to WOW64_CONTEXT
defined, for storing and handling the CPU state of an ARM32 process
from an ARM64 process. Thus, making an ARM64 lldb-server able to
control ARM32 processes seems infeasible at the moment.
(The normal CONTEXT struct has a different layout on each architecture.
In addition to this, a WOW64_CONTEXT struct always is defined, that
can store the CPU state of an x86_32 process, to allow handling it from
an x86_64 process. But there's no similar universally available struct
for ARM32.)
Summary:
It is inherently unsafe to allow a python program to manipulate borrowed
memory from a python object's destructor. It would be nice to
flush a borrowed file when python is finished with it, but it's not safe
to do on python 2.
Python 3 does not suffer from this issue.
Reviewers: labath, mgorny
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69532
The architecture enum contains two kinds of contstants: the "official" ones
defined by Microsoft, and unofficial constants added by breakpad to cover the
architectures not described by the first ones.
Up until now, there was no big need to differentiate between the two. However,
now that Microsoft has defined
https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/ns-sysinfoapi-system_info
a constant for ARM64, we have a name clash.
This patch renames all breakpad-defined constants with to include the prefix
"BP_". This frees up the name "ARM64", which I'll re-introduce with the new
"official" value in a follow-up patch.
Reviewers: amccarth, clayborg
Subscribers: lldb-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D69285
Summary:
This enables us to reason about whether a given address can be
executable, for instance during unwinding.
Reviewers: amccarth, mstorsjo
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D69102
Summary:
Move breakpoints from the old, bad ArgInfo::count to the new, better
ArgInfo::max_positional_args. Soon ArgInfo::count will be no more.
It looks like this functionality is already well tested by
`TestBreakpointCommandsFromPython.py`, so there's no need to write
additional tests for it.
Reviewers: labath, jingham, JDevlieghere
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69468
Summary:
Here's another instance where we were calling fflush on an input
stream, which is illegal on NetBSD.
Reviewers: labath, mgorny
Reviewed By: mgorny
Subscribers: krytarowski, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69488
The virtual container/header section caused the section list to be
offset by one, but by using FindSectionByID, the layout of the
section list shouldn't matter.
Differential Revision: https://reviews.llvm.org/D69366
Summary:
We add support for DW_AT_export_symbols to detect anonymous struct on top of the heuristics implemented in D66175
This should allow us to differentiate anonymous structs and unnamed structs.
We also fix TestTypeList.py which was incorrectly detecting an unnamed struct as an anonymous struct.
Differential Revision: https://reviews.llvm.org/D68961
The goal of this refactor is to enable ProcessMinidump to take into
account the loaded modules and their sections when computing the
permissions of various ranges of memory, as discussed in D66638.
This patch moves some of the responsibility for computing the ranges
from MinidumpParser into ProcessMinidump. MinidumpParser still does the
parsing, but ProcessMinidump becomes responsible for answering the
actual queries about memory ranges. This will enable it (in a follow-up
patch) to augment the information obtained from the parser with data
obtained from actual object files.
The changes in the actual code are fairly straight-forward and just
involve moving code around. MinidumpParser::GetMemoryRegions is renamed
to BuildMemoryRegions to emphasize that it does no caching. The only new
thing is the additional bool flag returned from this function. This
indicates whether the returned regions describe all memory mapped into
the target process. Data obtained from /proc/maps and the MemoryInfoList
stream is considered to be exhaustive. Data obtained from Memory(64)List
is not. This will be used to determine whether we need to augment the
data or not.
This reshuffle means that it is no longer possible/easy to test some of
this code via unit tests, as constructing a ProcessMinidump instance is
hard. Instead, I update the unit tests to only test the parsing of the
actual data, and test the answering of queries through a lit test using
the "memory region" command. The patch also includes some tweaks to the
MemoryRegion class to make the unit tests easier to write.
Reviewers: amccarth, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D69035
In an attempt to ensure that every part of the module's memory image is
accounted for, D56537 created a special "container section" spanning the
entire image. While that seemed reasonable at the time (and it still
mostly does), it did create a problem of what to put as the "file size"
of the section, because the image is not continuous on disk, as we
generally assume (which is why I put zero there). Additionally, this
arrangement makes it unclear what kind of permissions should be assigned
to that section (which is what my next patch does).
To get around these, this patch partially reverts D56537, and goes back
to top-level sections. Instead, what I do is create a new "section" for
the object file header, which is also being loaded into memory, though
its not considered to be a section in the strictest sense. This makes it
possible to correctly assign file size section, and we can later assign
permissions to it as well.
Reviewers: amccarth, mstorsjo
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D69100
For example, it is pretty easy to write a breakpoint command that implements "stop when my caller is Foo", and
it is pretty easy to write a breakpoint command that implements "stop when my caller is Bar". But there's no
way to write a generic "stop when my caller is..." function, and then specify the caller when you add the
command to a breakpoint.
With this patch, you can pass this data in a SBStructuredData dictionary. That will get stored in
the PythonCommandBaton for the breakpoint, and passed to the implementation function (if it has the right
signature) when the breakpoint is hit. Then in lldb, you can say:
(lldb) break com add -F caller_is -k caller_name -v Foo
More generally this will allow us to write reusable Python breakpoint commands.
Differential Revision: https://reviews.llvm.org/D68671
Summary:
When creating a FileSP object, do not flush() the underlying file unless
it is open for writing. Attempting to flush() a read-only fd results
in EBADF on NetBSD.
Reviewers: lawrence_danna, labath, krytarowski
Reviewed By: lawrence_danna, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D69320
MipsMCAsmInfo was using '$' prefix for Mips32 and '.L' for Mips64
regardless of -target-abi option. By passing MCTargetOptions to MCAsmInfo
we can find out Mips ABI and pick appropriate prefix.
Tags: #llvm, #clang, #lldb
Differential Revision: https://reviews.llvm.org/D66795
The field holding the "ro" will now be a union. If the low bit is set,
then it isn't an ro and it needs to be dereferenced once more to get to
it. If the low bit isn't set, then it is a proper class_ro_t
No dedicated test is needed as this code path will trigger when running
the existing Objective-C tests under a current version of the runtime.
Summary:
With this patch, only the no-argument form of `Reset()` remains in
PythonDataObjects. It also deletes PythonExceptionState in favor of
PythonException, because the only call-site of PythonExceptionState was
also using Reset, so I cleaned up both while I was there.
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69214
llvm-svn: 375475
Summary:
This deletes `Reset(...)`, except for the no-argument form `Reset()`
from `TypedPythonObject`, and therefore from `PythonString`, `PythonList`,
etc.
It updates the various callers to use assignment, `As<>`, `Take<>`,
and `Retain<>`, as appropriate.
followon to https://reviews.llvm.org/D69080
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69133
llvm-svn: 375350
Summary:
When users define a debugger command from python, they provide a callable
object. Because the signature of the function has been extended, LLDB
needs to inspect the number of parameters the callable can take.
The rule it was using to decide was weird, apparently not tested, and
giving wrong results for some kinds of python callables.
This patch replaces the weird rule with a simple one: if the callable can
take 5 arguments, it gets the 5 argument version of the signature.
Otherwise it gets the old 4 argument version.
It also adds tests with a bunch of different kinds of python callables
with both 4 and 5 arguments.
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69014
llvm-svn: 375333
Summary:
The minidump exception stream can report an exception record with
signal 0. If we try to create a stop reason with signal zero, processing
of the stop event won't find anything, and the debugger will hang.
So, simply early-out of RefreshStateAfterStop in this case.
Also set the UnixSignals object in DoLoadCore as is done for
ProcessElfCore.
Reviewers: labath, clayborg, jfb
Reviewed By: labath, clayborg
Subscribers: dexonsmith, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68096
llvm-svn: 375244
Summary: The types defined for it in LLDB are now redundant with core types.
Reviewers: labath, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68658
llvm-svn: 375243
Summary:
I'd like to eliminate all forms of Reset() and all public constructors
on these objects, so the only way to make them is with Take<> and Retain<>
and the only way to copy or move them is with actual c++ copy, move, or
assignment.
This is a simple place to start.
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69080
llvm-svn: 375182
Summary:
The current implementation of PythonCallable::GetNumArguments
is not exception safe, has weird semantics, and is just plain
incorrect for some kinds of functions.
Python 3.3 introduces inspect.signature, which lets us easily
query for function signatures in a sane and documented way.
This patch leaves the old implementation in place for < 3.3,
but uses inspect.signature for modern pythons. It also leaves
the old weird semantics in place, but with FIXMEs grousing about
it. We should update the callers and fix the semantics in a
subsequent patch. It also adds some tests.
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68995
llvm-svn: 375181
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
Summary:
When we have a artificial constructor DIE, we currently create from that a global function with the name of that class.
That ends up causing a bunch of funny errors such as "must use 'struct' tag to refer to type 'Foo' in this scope" when
doing `Foo f`. Also causes that constructing a class via `Foo()` actually just calls that global function.
The fix is that when we have an artificial method decl, we always treat it as handled even if we don't create a CXXMethodDecl
for it (which we never do for artificial methods at the moment).
Fixes rdar://55757491 and probably some other radars.
Reviewers: aprantl, vsk, shafik
Reviewed By: aprantl
Subscribers: jingham, shafik, labath, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68130
llvm-svn: 375151
Summary:
ScriptInterpreterPython needs to save and restore sys.stdout and
friends when LLDB runs a python script.
It currently does this using FILE*, which is not optimal. If
whatever was in sys.stdout can not be represented as a FILE*, then
it will not be restored correctly when the script is finished.
It also means that if the debugger's own output stream is not
representable as a file, ScriptInterpreterPython will not be able
to redirect python's output correctly.
This patch updates ScriptInterpreterPython to represent files with
lldb_private::File, and to represent whatever the user had in
sys.stdout as simply a PythonObject.
This will make lldb interoperate better with other scripts or programs
that need to manipulate sys.stdout.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68962
llvm-svn: 374964
Summary:
This patch eliminates a bunch of boilerplate from
PythonDataObjects, as well as the use of virtual methods.
In my opinion it also makes the Reset logic a lot more
clear and easy to follow. The price is yet another
template. I think it's worth it.
Reviewers: JDevlieghere, jasonmolenda, labath, zturner
Reviewed By: JDevlieghere, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68918
llvm-svn: 374916
Summary:
This makes SBFile::GetFile public and adds a SWIG typemap to convert
the result back into a python native file.
If the underlying File itself came from a python file, it is returned
identically. Otherwise a new python file object is created using
the file descriptor.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68737
llvm-svn: 374911
This matches all other architectures listed in the same file.
This fixes debugging aarch64 executables with lldb-server, which
otherwise fails, with log messages like these:
Target::SetArchitecture changing architecture to aarch64 (aarch64-pc-windows-msvc)
Target::SetArchitecture Trying to select executable file architecture aarch64 (aarch64-pc-windows-msvc)
ArchSpec::SetArchitecture sets the vendor to llvm::Triple::PC
for any coff/win32 combination, and if this doesn't match the triple
set by the PECOFF module, things doesn't seem to work with when
using lldb-server.
Differential Revision: https://reviews.llvm.org/D68939
llvm-svn: 374867
Summary:
This patch re-types everywhere that passes a File::OpenOptions
as a uint32_t so it actually uses File::OpenOptions.
It also converts some OpenOptions related functions that fail
by returning 0 or NULL into llvm::Expected
split off from https://reviews.llvm.org/D68737
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68853
llvm-svn: 374817
Summary:
For context: https://reviews.llvm.org/D68293
We need a way to show all the processes on android regardless of the user id.
When you run `platform process list`, you only see the processes with the same user as the user that launched lldb-server. However, it's quite useful to see all the processes, though, and it will lay a foundation for full apk debugging support from lldb.
Before:
```
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
3234 1 aarch64-unknown-linux-android adbd
8034 3234 aarch64-unknown-linux-android sh
9096 3234 aarch64-unknown-linux-android sh
9098 9096 aarch64-unknown-linux-android lldb-server
(lldb) ^D
```
Now:
```
(lldb) platform process list -x
205 matching processes were found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
1 0 init
524 1 init
525 1 init
531 1 ueventd
568 1 logd
569 1 aarch64-unknown-linux-android servicemanager
570 1 aarch64-unknown-linux-android hwservicemanager
571 1 aarch64-unknown-linux-android vndservicemanager
577 1 aarch64-unknown-linux-android qseecomd
580 577 aarch64-unknown-linux-android qseecomd
...
23816 979 com.android.providers.calendar
24600 979 com.verizon.mips.services
27888 979 com.hualai
28043 2378 com.android.chrome:sandboxed_process0
31449 979 com.att.shm
31779 979 com.samsung.android.authfw
31846 979 com.samsung.android.server.iris
32014 979 com.samsung.android.MtpApplication
32045 979 com.samsung.InputEventApp
```
Reviewers: labath,xiaobai,aadsm,clayborg
Subscribers:
> llvm-svn: 374584
llvm-svn: 374631
Summary:
For context: https://reviews.llvm.org/D68293
We need a way to show all the processes on android regardless of the user id.
When you run `platform process list`, you only see the processes with the same user as the user that launched lldb-server. However, it's quite useful to see all the processes, though, and it will lay a foundation for full apk debugging support from lldb.
Before:
```
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
3234 1 aarch64-unknown-linux-android adbd
8034 3234 aarch64-unknown-linux-android sh
9096 3234 aarch64-unknown-linux-android sh
9098 9096 aarch64-unknown-linux-android lldb-server
(lldb) ^D
```
Now:
```
(lldb) platform process list -x
205 matching processes were found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
1 0 init
524 1 init
525 1 init
531 1 ueventd
568 1 logd
569 1 aarch64-unknown-linux-android servicemanager
570 1 aarch64-unknown-linux-android hwservicemanager
571 1 aarch64-unknown-linux-android vndservicemanager
577 1 aarch64-unknown-linux-android qseecomd
580 577 aarch64-unknown-linux-android qseecomd
...
23816 979 com.android.providers.calendar
24600 979 com.verizon.mips.services
27888 979 com.hualai
28043 2378 com.android.chrome:sandboxed_process0
31449 979 com.att.shm
31779 979 com.samsung.android.authfw
31846 979 com.samsung.android.server.iris
32014 979 com.samsung.android.MtpApplication
32045 979 com.samsung.InputEventApp
```
Reviewers: labath,xiaobai,aadsm,clayborg
Subscribers:
> llvm-svn: 374584
llvm-svn: 374626
Summary:
For context: https://reviews.llvm.org/D68293
We need a way to show all the processes on android regardless of the user id.
When you run `platform process list`, you only see the processes with the same user as the user that launched lldb-server. However, it's quite useful to see all the processes, though, and it will lay a foundation for full apk debugging support from lldb.
Before:
```
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
3234 1 aarch64-unknown-linux-android adbd
8034 3234 aarch64-unknown-linux-android sh
9096 3234 aarch64-unknown-linux-android sh
9098 9096 aarch64-unknown-linux-android lldb-server
(lldb) ^D
```
Now:
```
(lldb) platform process list -x
205 matching processes were found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
1 0 init
524 1 init
525 1 init
531 1 ueventd
568 1 logd
569 1 aarch64-unknown-linux-android servicemanager
570 1 aarch64-unknown-linux-android hwservicemanager
571 1 aarch64-unknown-linux-android vndservicemanager
577 1 aarch64-unknown-linux-android qseecomd
580 577 aarch64-unknown-linux-android qseecomd
...
23816 979 com.android.providers.calendar
24600 979 com.verizon.mips.services
27888 979 com.hualai
28043 2378 com.android.chrome:sandboxed_process0
31449 979 com.att.shm
31779 979 com.samsung.android.authfw
31846 979 com.samsung.android.server.iris
32014 979 com.samsung.android.MtpApplication
32045 979 com.samsung.InputEventApp
```
Reviewers: labath,xiaobai,aadsm,clayborg
Subscribers:
> llvm-svn: 374584
llvm-svn: 374622
Summary:
For context: https://reviews.llvm.org/D68293
We need a way to show all the processes on android regardless of the user id.
When you run `platform process list`, you only see the processes with the same user as the user that launched lldb-server. However, it's quite useful to see all the processes, though, and it will lay a foundation for full apk debugging support from lldb.
Before:
```
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
3234 1 aarch64-unknown-linux-android adbd
8034 3234 aarch64-unknown-linux-android sh
9096 3234 aarch64-unknown-linux-android sh
9098 9096 aarch64-unknown-linux-android lldb-server
(lldb) ^D
```
Now:
```
(lldb) platform process list -x
205 matching processes were found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
1 0 init
524 1 init
525 1 init
531 1 ueventd
568 1 logd
569 1 aarch64-unknown-linux-android servicemanager
570 1 aarch64-unknown-linux-android hwservicemanager
571 1 aarch64-unknown-linux-android vndservicemanager
577 1 aarch64-unknown-linux-android qseecomd
580 577 aarch64-unknown-linux-android qseecomd
...
23816 979 com.android.providers.calendar
24600 979 com.verizon.mips.services
27888 979 com.hualai
28043 2378 com.android.chrome:sandboxed_process0
31449 979 com.att.shm
31779 979 com.samsung.android.authfw
31846 979 com.samsung.android.server.iris
32014 979 com.samsung.android.MtpApplication
32045 979 com.samsung.InputEventApp
```
Reviewers: labath,xiaobai,aadsm,clayborg
Subscribers:
> llvm-svn: 374584
llvm-svn: 374620
Summary:
For context: https://reviews.llvm.org/D68293
We need a way to show all the processes on android regardless of the user id.
When you run `platform process list`, you only see the processes with the same user as the user that launched lldb-server. However, it's quite useful to see all the processes, though, and it will lay a foundation for full apk debugging support from lldb.
Before:
```
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
3234 1 aarch64-unknown-linux-android adbd
8034 3234 aarch64-unknown-linux-android sh
9096 3234 aarch64-unknown-linux-android sh
9098 9096 aarch64-unknown-linux-android lldb-server
(lldb) ^D
```
Now:
```
(lldb) platform process list -x
205 matching processes were found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
1 0 init
524 1 init
525 1 init
531 1 ueventd
568 1 logd
569 1 aarch64-unknown-linux-android servicemanager
570 1 aarch64-unknown-linux-android hwservicemanager
571 1 aarch64-unknown-linux-android vndservicemanager
577 1 aarch64-unknown-linux-android qseecomd
580 577 aarch64-unknown-linux-android qseecomd
...
23816 979 com.android.providers.calendar
24600 979 com.verizon.mips.services
27888 979 com.hualai
28043 2378 com.android.chrome:sandboxed_process0
31449 979 com.att.shm
31779 979 com.samsung.android.authfw
31846 979 com.samsung.android.server.iris
32014 979 com.samsung.android.MtpApplication
32045 979 com.samsung.InputEventApp
```
Reviewers: labath,xiaobai,aadsm,clayborg
Subscribers:
> llvm-svn: 374584
llvm-svn: 374609
Summary:
For context: https://reviews.llvm.org/D68293
We need a way to show all the processes on android regardless of the user id.
When you run `platform process list`, you only see the processes with the same user as the user that launched lldb-server. However, it's quite useful to see all the processes, though, and it will lay a foundation for full apk debugging support from lldb.
Before:
```
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
3234 1 aarch64-unknown-linux-android adbd
8034 3234 aarch64-unknown-linux-android sh
9096 3234 aarch64-unknown-linux-android sh
9098 9096 aarch64-unknown-linux-android lldb-server
(lldb) ^D
```
Now:
```
(lldb) platform process list -x
205 matching processes were found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
1 0 init
524 1 init
525 1 init
531 1 ueventd
568 1 logd
569 1 aarch64-unknown-linux-android servicemanager
570 1 aarch64-unknown-linux-android hwservicemanager
571 1 aarch64-unknown-linux-android vndservicemanager
577 1 aarch64-unknown-linux-android qseecomd
580 577 aarch64-unknown-linux-android qseecomd
...
23816 979 com.android.providers.calendar
24600 979 com.verizon.mips.services
27888 979 com.hualai
28043 2378 com.android.chrome:sandboxed_process0
31449 979 com.att.shm
31779 979 com.samsung.android.authfw
31846 979 com.samsung.android.server.iris
32014 979 com.samsung.android.MtpApplication
32045 979 com.samsung.InputEventApp
```
Reviewers: labath,xiaobai,aadsm,clayborg
Subscribers:
llvm-svn: 374584
Summary:
Currently when invoking lldb-test symbols -dump-ast it parses all the debug symbols and calls print(...) on the TranslationUnitDecl.
While useful the TranslationUnitDecl::print(...) method gives us a higher level view then the dump from ASTDumper which is what we get when we invoke dump() on a specific AST node.
The main motivation for this change is allow us to verify that the AST nodes we create when we parse DWARF. For example in order to verify we are correctly using DIFlagExportSymbols added by D66667
Differential Revision: https://reviews.llvm.org/D67994
llvm-svn: 374570
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
Summary:
After rLLDB365761, and with `LLVM_ENABLE_ABI_BREAKING_CHECKS` enabled,
launching any process on FreeBSD crashes lldb with:
```
Expected<T> must be checked before access or destruction.
Expected<T> value was in success state. (Note: Expected<T> values in success mode must still be checked prior to being destroyed).
```
This is because `m_operation_thread` and `m_monitor_thread` were wrapped
in `llvm::Expected<>`, but this requires the objects to be correctly
initialized before accessing them.
To fix the crashes, use `llvm::Optional<>` for the members (as indicated
by labath), and use local variables to store the return values of
`LaunchThread` and `StartMonitoringChildProcess`. Then, only assign to
the member variables after checking if the return values indicated
success.
Reviewers: devnexen, emaste, MaskRay, mgorny
Reviewed By: devnexen
Subscribers: jfb, labath, krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D68723
llvm-svn: 374444
When debugging a large program like clang and doing "frame variable
*this", the ValueObject pretty printer is doing hundreds of scoped
FindTypes lookups. The ones that take longest are the ones where the
DWARFDeclContext ends in something like ::Iterator which produces many
false positives that need to be filtered out *after* extracting the
DIEs. This patch demonstrates a way to filter out false positives at
the accerator table lookup step.
With this patch
lldb clang-10 -o "b EmitFunctionStart" -o r -o "f 2" -o "fr v *this" -b -- ...
goes (in user time) from 5.6s -> 4.8s
or (in wall clock) from 6.9s -> 6.0s.
Differential Revision: https://reviews.llvm.org/D68678
llvm-svn: 374401
Raphael Isemann