Add support for compressed CTF data. The flags in the header can
indicate whether the CTF body is compressed with zlib deflate. This
patch supports inflating the data before parsing.
Differential revision: https://reviews.llvm.org/D155221
Add support for the Compact C Type Format (CTF) in LLDB. The format
describes the layout and sizes of C types. It is most commonly consumed
by dtrace.
We generate CTF for the XNU kernel and want to be able to use this in
LLDB to debug kernels for which we don't have dSYMs (anymore). CTF is a
much more limited debug format than DWARF which allows is to be an order
of magnitude smaller: a 1GB dSYM can be converted to a handful of
megabytes of CTF. For XNU, the goal is not to replace DWARF, but rather
to have CTF serve as a "better than nothing" debug info format when
DWARF is not available.
It's worth noting that the LLVM toolchain does not support emitting CTF.
XNU uses ctfconvert to generate CTF from DWARF which is used for
testing.
Differential revision: https://reviews.llvm.org/D154862
This code was introduced in 2fc93eabf7.
In order to improve readability of ParseVariableDIE, we move this code into a
helper function. The issue this code attempted to address was fixed between
Clangs 9 and 11; as such, if we ever want to delete this code, it is a lot
easier to do so after the refactor.
Differential Revision: https://reviews.llvm.org/D155100
I need to call this to figure out why the assert in
StopInfoMachException::CreateStopReasonWithMachException is triggering, but
it isn't appropriate to directly access the GDBRemoteCommunication there. And
dumping whatever history the process plugin has collected during the run isn't
gdb-remote specific...
Differential Revision: https://reviews.llvm.org/D154992
These methods all take a `Stream *` to get feedback about what's going
on. By default, it's a nullptr, but we always feed it with a valid
pointer. It would therefore make more sense to have this take a
reference.
Differential Revision: https://reviews.llvm.org/D154883
`Instruction::TestEmulation` takes a `Stream *` and checks it for validity.
However, this is unnecessary as we can always ensure that we never pass
`nullptr` for the `Stream` argument. The only use of
`Instruction::TestEmulation` currently is `SBInstruction::TestEmulation`
which gets the `Stream` from an `SBStream`, and `SBStream::ref` can
return a `Stream &` guaranteed.
Differential Revision: https://reviews.llvm.org/D154757
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
This is fixing all files missed in b0abd4893f, 39d8e6e22c, and
a11efd4926.
Differential Revision: https://reviews.llvm.org/D154775
In order to recognize namespace aliases as a namespace, the
DW_TAG_imported_declaration has to be taken into account. The name of these DIEs
is already included in all accelerator tables as of D143397.
Two of the three Index classes already handle this correctly:
1. ManualDWARFIndex (as of D143398)
2. AppleDWARFIndex works by default with D143397, since apple has a table
dedicated to namespaces.
This commit updates the third index class, DWARF 5's DebugNamesDWARFIndex.
As a result, it fixes the following test with DWARF 5:
commands/expression/namespace-alias/TestInlineNamespaceAlias.py
Differential Revision: https://reviews.llvm.org/D154730
dyld has two notification functions - a native one, and one that
it rewrites its arguments for, for lldb. We currently use the
latter, _dyld_debugger_notification. The native notification
function, lldb_image_notifier (and on older systems, gdb_image_notifier)
we can find by name, or if libdyld shows no dyld loaded in the
process currently, we can get it from the dyld_all_image_infos
object in memory which we can find with a system call. When we do
a "waitfor attach" to a process on a modern darwin system, there
is a transition early in launch from the launch dyld to the
shared-cache-dyld, and when we attach in the middle of that transition,
libdyld will say there is no dyld present. But we can still find
the in-memory dyld_all_image_infos which has the address of the
shared cache notifier function that will be registered in the
process soon.
This change will result in a much more reliable waitfor-attach.
This is the third landing of this patch. We have an Intel mac
CI bot that is running an older (c. 2019) macOS 10.15, I had to
reproduce that environment and found the name of the notifier
function had changed which was the cause of those failures.
Differential Revision: https://reviews.llvm.org/D139453
rdar://101194149
We always assume these streams are valid, might as well take references
instead of raw pointers.
Differential Revision: https://reviews.llvm.org/D154549
This function does a _lot_ of different things:
1. Parses a DIE,
2. Builds an ExpressionList
3. Figures out lifetime of variable
4. Remaps addresses for debug maps
5. Handles external variables
6. Figures out scope of variables
A lot of this functionality is coded in a complex nest of conditions, variables
that are declared and then initialized much later, variables that are updated in
multiple code paths. All of this makes the code really hard to follow.
This commit attempts to improve the state of things by factoring out (3), adding
documentation on how the expression list is built, and by reducing the scope of
variables.
Differential Revision: https://reviews.llvm.org/D154513
On Darwin systems, the dynamic linker dyld has an empty function
it calls when binaries are added/removed from the process. lldb puts
a breakpoint on this dyld function to catch the notifications. The
function arguments are used by lldb to tell what is happening.
The linker has a natural representation when the addresses of
binaries being added/removed are in the pointer size of the process.
There is then a second function where the addresses of the binaries
are in a uint64_t array, which the debugger has been using before -
dyld allocates memory for the array, copies the values in to it,
and calls it for lldb's benefit.
This changes to using the native notifier function, with pointer-sized
addresses.
This is the second time landing this change; this time correct the
size of the image_count argument, and add a fallback if the
notification function "lldb_image_notifier" can't be found.
Differential Revision: https://reviews.llvm.org/D139453
This patch attempts to fix a dead lock when loading modules in a Scripted
Process.
This issue was triggered by loading the modules after the process did resume,
but before the process actually stop, causing the language runtime mutex to
be locked by a separate thread, responsible to unwind the stack (using
the runtime unwind plan), while the module loading thread was trying to
notify the runtimes of the newly loaded module.
To address that, this patch moves the module loading logic to be done before
sending the stop event, to prevent the dead lock situation described above.
Differential Revision: https://reviews.llvm.org/D154649
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
When LLDB queries the debug names index with a regex, we should use the
`Mangled` class wrapper, which attempts to match regex first against the mangled
name and then against the demangled name. It is important to do so, otherwise
queries like `frame var --regex A::` would never work. This is what is done for
the Apple index as well.
This fixes test/API/lang/cpp/class_static/main.cpp when compiled with DWARF 5.
Differential Revision: https://reviews.llvm.org/D154617
Two identical loops were iterating over different ranges, leading to code
duplication. We replace this by a loop over the concatenation of the ranges.
We also use early returns to avoid deeply nested code and explicitly check for a
condition mentioned in comments.
Differential Revision: https://reviews.llvm.org/D154505
We're seeing a lot of test failures on the lldb incremental x86 CI bot
since I landed https://reviews.llvm.org/D139453 - revert it while I
investigate.
This reverts commit 624813a4f4.
Fix incorrect uses of LLDB_LOG_ERROR. The macro doesn't automatically
inject the error in the log message: it merely passes the error as the
first argument to formatv and therefore must be referenced with {0}.
Thanks to Nicholas Allegra for collecting a list of places where the
macro was misused.
rdar://111581655
Differential revision: https://reviews.llvm.org/D154530
The make_shared function never returns a nullptr, as such the test for nullptr
is not needed. We also move the empty string check earlier in the if
("oso_object"), as this is cheaper than loading the object file.
Differential Revision: https://reviews.llvm.org/D154365
This patch should fix some data races when a python script (i.e. a
Scripted Process) has a nested call to another python script (i.e. a
OperatingSystem Plugin), which can cause concurrent writes to the python
lock count.
This patch also fixes a data race happening when resetting the operating
system unique pointer.
To address these issues, both accesses is guarded by a mutex.
rdar://109413039
Differential Revision: https://reviews.llvm.org/D154271
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
I'm not convinced that it makes sense for the paths to be ConstStrings. We're
going to be putting them into FileSpecs (which are backed by
ConstStrings, for now) but otherwise there's no need to store them as
ConstStrings upfront.
Differential Revision: https://reviews.llvm.org/D153827
Instead of just returning a raw `const char *`, I think llvm::StringRef
would make more sense. Most of the time that we use the return value of
`GetProcessPluginName` we're passing it to `CreateProcess` which takes a
StringRef anyway.
Differential Revision: https://reviews.llvm.org/D153825
This doesn't really use fast comparison or string uniqueness. In fact,
all of the current callers pass an empty string for type_name. The only
reason I don't remove it is because it looks like it is used downstream
for swift.
Differential Revision: https://reviews.llvm.org/D153810
2/3 of the ConstStrings in this class were just to be able to log
something. Putting something in the StringPool just to log it doesn't
make a lot of sense, so let's remove them.
The remaining use is for `RegisterPersistentDecl` which is fine for now.
Differential Revision: https://reviews.llvm.org/D153905
A very old commit (9422dd64f8) changed the signature of this function in a
number of ways. This patch aims to improve it:
1. Reword the documentation, which still mentions old parameters that no longer
exist, and to elaborate upon the behavior of this function.
2. Remove the unnecessary parameter `op_addr_idx`. This parameter is odd in a
couple of ways: we never use it with a value that is non-zero, and the matching
`Update_DW_OP_addr` function doesn't use a similar parameter. We also document
that this new behavior. If we ever decide to handle multiple "DW_OP_addr", we
can introduce the complexity again.
Differential Revision: https://reviews.llvm.org/D154265
On Darwin systems, the dynamic linker dyld has an empty function
it calls when binaries are added/removed from the process. lldb puts
a breakpoint on this dyld function to catch the notifications. The
function arguments are used by lldb to tell what is happening.
The linker has a natural representation when the addresses of
binaries being added/removed are in the pointer size of the process.
There is then a second function where the addresses of the binaries
are in a uint64_t array, which the debugger has been using before -
dyld allocates memory for the array, copies the values in to it,
and calls it for lldb's benefit.
This changes to using the native notifier function, with pointer-sized
addresses.
Differential Revision: https://reviews.llvm.org/D139453
The `RewriteObjCClassReferences` pass was applicable only to the code generated for the
fragile ObjC ABI (v1). That ABI is no longer active (last used for i386 macOS), which
means this pass has no effect.
Sources: `OBJC_CLASS_REFERENCES_` is emitted only by `CGObjCMac`, and not by
`CGObjCNonFragileABIMac`.
Differential Revision: https://reviews.llvm.org/D153802
While looking at https://github.com/llvm/llvm-project/issues/61955
I noticed that when we send qLaunchGDBServer we check that we got a response
but not what kind of response it was.
I think this was why the bug reporter saw:
(lldb) run
error: invalid host:port specification: '[192.168.64.2]'
The missing port is because we went down a path we only should have
chosen if the operation succeeded. Since we didn't check, we went ahead
with an empty port number.
To test this I've done the following:
* Make a temporary copy of lldb-server.
* Run that as a platform.
* Remove the copy.
* Attempt to create and run a target.
This fails because the running lldb-server will try to invoke itself
and it no longer exists.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D153513
ObjectFileMachO::SetLoadAddress() should allow for a DATA segment
that has no file content to be slid in the vmaddr, it is valid
to have such a section.
Differential Revision: https://reviews.llvm.org/D154037
rdar://99744343
This commit is replacing really old LLDB code, and we've found some odd
behavior while doing this replacement. While the changes here are largely NFC,
there are some subtle changes that fix such odd behavior.
The most curious example of this is the method `FindCompleteObjCClassName`,
which has a flag `must_be_implementation`. This flag was _only_ being respected
for accelerator tables containing the atom `type_flags`, which seems
counter-intuitive. The implementation for DWARF 5 tables does not do that and
neither does the code introduced in this patch.
There were other weird cases, for example, we found boolean logic that was
always true in a code path: look for a `if !has_qualified_name...` deleted
line; that condition was true by simple if/else analysis.
Differential Revision: https://reviews.llvm.org/D153867
All the new code should match the behavior of the old exactly.
Of note, the custom queries used to be implemented inside `HashedNameToDIE.cpp`
(which is the LLDB implementation of the tables). However, when porting to LLVM,
we believe they don't belong inside the LLVM table implementation:
1. They don't require any knowledge about the table itself
2. They are not relevant for other users of these classes.
3. They use LLDB data structures.
As such, we implement these custom queries inside AppleDWARFIndex.cpp.
Types and Objective-C tables are done separately, as they have slightly
different functionality that require rewriting more code.
Differential Revision: https://reviews.llvm.org/D153866
While working on the broken-symlinks issue, I noticed this one place
where I was setting `find_other` to false unintentionally in the
darwin kernel platform kext/kernel scan. Small fix while I'm here.
LLDB's implementation of DWARFDataExtractor has a method that returns a
llvm::DWARFDataExtractor. In some cases, like DebugNamesDWARFIndex::Create, we
were passing an LLVM::DWARFDataExtractor to a function that expects a
LLVM:DataExtractor by value. This is causing slicing of the derived class.
While slicing is not inherently bad, it can be dangerous if the constructor of
the derived class mutates the base class in a way that leaves it in an invalid
state after slicing.
Differential Revision: https://reviews.llvm.org/D153913
Previously lldb was using arrays of size kMaxRegisterByteSize to handle
registers. This was set to 256 because the largest possible register
we support is Arm's scalable vectors (SVE) which can be up to 256 bytes long.
This means for most operations aside from SVE, we're wasting 192 bytes
of it. Which is ok given that we don't have to pay the cost of a heap
alocation and 256 bytes isn't all that much overall.
With the introduction of the Arm Scalable Matrix extension there is a new
array storage register, ZA. This register is essentially a square made up of
SVE vectors. Therefore ZA could be up to 64kb in size.
https://developer.arm.com/documentation/ddi0616/latest/
"The Effective Streaming SVE vector length, SVL, is a power of two in the range 128 to 2048 bits inclusive."
"The ZA storage is architectural register state consisting of a two-dimensional ZA array of [SVLB × SVLB] bytes."
99% of operations will never touch ZA and making every stack frame 64kb+ just
for that slim chance is a bad idea.
Instead I'm switching register handling to use SmallVector with a stack allocation
size of kTypicalRegisterByteSize. kMaxRegisterByteSize will be used in places
where we can't predict the size of register we're reading (in the GDB remote client).
The result is that the 99% of small register operations can use the stack
as before and the actual ZA operations will move to the heap as needed.
I tested this by first working out -wframe-larger-than values for all the
libraries using the arrays previously. With this change I was able to increase
kMaxRegisterByteSize to 256*256 without hitting those limits. With the
exception of the GDB server which needs to use a max size buffer.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D153626
The shared cache has grown past the previously hardcoded limit. As a
temporary measure, I am increasing the hardcoded number of classes we
can expect to read from the shared cache. This is not a good long-term
solution.
Differential Revision: https://reviews.llvm.org/D153817
The use of ConstString in StructuredDataPlugin is unneccessary as fast
comparisons are not neeeded for StructuredDataPlugins.
Differential Revision: https://reviews.llvm.org/D153482
The Objective-C runtime and the shared cache has changed slightly.
Given a class_ro_t, the baseMethods ivar is now a pointer union and may
either be a method_list_t pointer or a pointer to a relative list of
lists. The entries of this relative list of lists are indexes that refer
to a specific image in the shared cache in addition to a pointer offset
to find the accompanying method_list_t. We have to go over each of these
entries, parse it, and then if the relevant image is loaded in the
process, we add those methods to the relevant clang Decl.
In order to determine if an image is loaded, the Objective-C runtime
exposes a symbol that lets us determine if a particular image is loaded.
We maintain a data structure SharedCacheImageHeaders to keep track of
that information.
There is a known issue where if an image is loaded after we create a
Decl for a class, the Decl will not have the relevant methods from that
image (i.e. for Categories).
rdar://107957209
Differential Revision: https://reviews.llvm.org/D153597
This patch should address the failure of TestStackCoreScriptedProcess
that is happening specifically on x86_64.
It turns out that in 1370a1cb5b, I changed the way we extract integers
from a `StructuredData::Dictionary` and in order to get a stop info from
the scripted process, we call a method that returns a `SBStructuredData`
containing the stop reason data.
TestStackCoreScriptedProcess` was failing specifically on x86_64 because
the stop info dictionary contains the signal number, that the `Scripted
Thread` was trying to extract as a signed integer where it was actually
parsed as an unsigned integer. That caused `GetValueForKeyAsInteger` to
return the default value parameter, `LLDB_INVALID_SIGNAL_NUMBER`.
This patch address the issue by extracting the signal number with the
appropriate type and re-enables the test.
Differential Revision: https://reviews.llvm.org/D152848
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
