Our LLDB parser didn't correctly handle archives of all flavors on different systems, it currently only correctly handled BSD archives, normal and thin, on macOS, but I noticed that it was getting incorrect information when decoding a variety of archives on linux. There were subtle changes to how names were encoded that we didn't handle correctly and we also didn't set the result of GetObjectSize() correctly as there was some bad math. This didn't matter when exracting .o files from .a files for LLDB because the size was always way too big, but it was big enough to at least read enough bytes for each object within the archive.
This patch does the following:
- switch over to use LLVM's archive parser and avoids previous code duplication
- remove values from ObjectContainerBSDArchive::Object that we don't use like:
- uid
- gid
- mode
- fix ths ObjectContainerBSDArchive::Object::file_size value to be correct
- adds tests to test that we get the correct module specifications
Differential Revision: https://reviews.llvm.org/D159408
This always succeeds. While I'm here, document why we check the size
of p0 against the value of VG.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D157845
This method was working as expected if LLDB_ENABLE_LIBEDIT is false, however, if it was true, then the variable m_current_lines_ptr was always pointing to an empty list, because Editline only updates its contents once the full input has been completed (see https://github.com/llvm/llvm-project/blob/main/lldb/source/Host/common/Editline.cpp#L1576).
A simple fix is to invoke Editline::GetInputAsStringList() from GetCurrentLines(), which is already used in many places as the common way to get the full input list.
Add support for syntax color highlighting disassembly in LLDB. This
patch relies on 77d1032516e7, which introduces support for syntax
highlighting in MC.
Currently only AArch64 and X86 have color support, but other interested
backends can adopt WithColor in their respective MCInstPrinter.
Differential revision: https://reviews.llvm.org/D159164
Fixes#65157
07c215e8a8af54d0084af7291ac29fef3672fcd8 added some extra logging
which compiles ok with clang but not msvc. Use LLVM_PRETTY_FUNCTION
to fix that.
Fix suggested by Carlos Alberto Enciso.
In Apple's downstream fork, there is support for understanding the swift
AST sections in various binaries. Even though the lldb on llvm.org does
not have support for debugging swift, I think it makes sense to move
support for recognizing swift ast sections upstream.
Differential Revision: https://reviews.llvm.org/D159142
ConstString can be implicitly converted into a llvm::StringRef. This is
very useful in many places, but it also hides places where we are
creating a ConstString only to use it as a StringRef for the entire
lifespan of the ConstString object.
I locally removed the implicit conversion and found some of the places we
were doing this.
Differential Revision: https://reviews.llvm.org/D159237
The primary goal of this change is to change `if (pair != *(--m_dict.end()))`
to `if (std::next(iter) != m_dict.end())`. I was experimenting with
changing the underlying type of `m_dict` and found that this was an
issue. Specifically, it assumes that m_dict iterators are bidirectional.
This change should make it so we only need to assume m_dict iterators can move
forward.
Differential Revision: https://reviews.llvm.org/D159150
We ran into a case where shared libraries would fail to load in some processes on linux. The issue turned out to be if the main executable or a shared library defined a symbol named "_r_debug", then it would cause problems once the executable that contained it was loaded into the process. The "_r_debug" structure is currently found by looking through the .dynamic section in the main executable and finding the DT_DEBUG entry which points to this structure. The dynamic loader will update this structure as shared libraries are loaded and LLDB watches the contents of this structure as the dyld breakpoint is hit. Currently we expect the "state" in this structure to change as things happen. An issue comes up if someone defines another "_r_debug" struct in their program:
```
r_debug _r_debug;
```
If this code is included, a new "_r_debug" structure is created and it causes problems once the executable is loaded. This is because of the way symbol lookups happen in linux: they use the shared library list in the order it created and the dynamic loader is always last. So at some point the dynamic loader will start updating this other copy of "_r_debug", yet LLDB is only watching the copy inside of the dynamic loader.
Steps that show the problem are:
- lldb finds the "_r_debug" structure via the DT_DEBUG entry in the .dynamic section and this points to the "_r_debug" in ld.so
- ld.so modifies its copy of "_r_debug" with "state = eAdd" before it loads the shared libraries and calls the dyld function that LLDB has set a breakpoint on and we find this state and do nothing (we are waiting for a state of eConsistent to tell us the shared libraries have been fully loaded)
- ld.so loads the main executable and any dependent shared libraries and wants to update the "_r_debug" structure, but it now finds "_r_debug" in the a.out program and updates the state in this other copy
- lldb hits the notification breakpoint and checks the ld.so copy of "_r_debug" which still has a state of "eAdd". LLDB wants the new "eConsistent" state which will trigger the shared libraries to load, but it gets stale data and doesn't do anyhing and library load is missed. The "_r_debug" in a.out has the state set correctly, but we don't know which "_r_debug" is the right one.
The new fix detects the two "eAdd" states and loads shared libraries and will emit a log message in the "log enable lldb dyld" log channel which states there might be multiple "_r_debug" structs.
The correct solution is that no one should be adding a duplicate "_r_debug" symbol to their binaries, but we have programs that are doing this already and since it can be done, we should be able to work with this and keep debug sessions working as expected. If a user #includes the <link.h> file, they can just use the existing "_r_debug" structure as it is defined in this header file as "extern struct r_debug _r_debug;" and no local copies need to be made.
If your ld.so has debug info, you can easily see the duplicate "_r_debug" structs by doing:
```
(lldb) target variable _r_debug --raw
(r_debug) _r_debug = {
r_version = 1
r_map = 0x00007ffff7e30210
r_brk = 140737349972416
r_state = RT_CONSISTENT
r_ldbase = 0
}
(r_debug) _r_debug = {
r_version = 1
r_map = 0x00007ffff7e30210
r_brk = 140737349972416
r_state = RT_ADD
r_ldbase = 140737349943296
}
(lldb) target variable &_r_debug
(r_debug *) &_r_debug = 0x0000555555601040
(r_debug *) &_r_debug = 0x00007ffff7e301e0
```
And if you do a "image lookup --address <addr>" in the addresses, you can see one is in the a.out and one in the ld.so.
Adding more logging to print out the m_previous and m_current Rendezvous structures to make things more clear. Also added a log when we detect multiple eAdd states in a row to detect this problem in logs.
Differential Revision: https://reviews.llvm.org/D158583
- Allow the definition of synthetic formatters in C++ even when LLDB is built without python scripting support.
- Fix linking problems with the CXXSyntheticChildren
Differential Revision: https://reviews.llvm.org/D158010
When sending file from a Linux host to a Windows remote, Linux host will try to copy the source file's permission bits, which will contain `_S_I?GRP` and `_S_I?OTH` bits. Those bits are rejected by `_wsopen_s`, causing it to return EINVAL.
This patch masks out the rejected bits.
GitHub issue: #64313
Reviewed By: jasonmolenda, DavidSpickett
Differential Revision: https://reviews.llvm.org/D156817
This is the next step in removing ConstString from StructuredData. There
are StringRef overloads already, let's use those where we can.
Differential Revision: https://reviews.llvm.org/D152870
The REPL has a default tab size of 4 spaces, which seems to be a bit too much. The reason is that the REPL transforms tabs into spaces, and therefore whenever you want to manually deindent, you need to delete at least 4 characters. On the other hand, using 2 as default results in less keystrokes, without hurting readability.
The error message "Couldn't lookup symbols" emitted from IRExecutionUnit
is grammatically incorrect. "Lookup" is noun when spelled without a
space. Update the error message to use the verb "look up" instead.
Get the path to qemu in the following order:
1) From the property platform.plugin.qemu-user.emulator-path
2) If that property is not set, from PATH, building the name of the qemu
binary from the triple in property platform.plugin.qemu-user.architecture
3) If that property is not set, from PATH, building the name of the qemu
binary from the triple in the target
This will allow a user to load a target and run without setting properties,
if qemu is on the PATH and named qemu-<ArchName>
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D155117
llvm::MCInstPrinter has an option, controlled by setPrintBranchImmAsAddress,
to print branch targets as immediate addresses instead of offsets.
Turn this on in lldb, so targets that support this flag will print addresses
instead of offsets.
This requires the address of the instruction be provided, but fortunately
it's calculated right before the call to PrintMCInst.
Reviewed By: jasonmolenda, DavidSpickett
Differential Revision: https://reviews.llvm.org/D155107
There's no reason for GetSignalInfo to return the signal name. All users
of this method only use the return value to determine if the method
succeeded in filling in the output parameters, so let's explicitly make
it a bool instead of a pointer.
Differential Revision: https://reviews.llvm.org/D158457
Apple maintains a downstream fork of lldb in order to support swift
debugging. Much of that support is isolated to its own plugins, but some
of it is exposed in more generic code. I would like to take some of
the swift support we have downstream and move it upstream to llvm.org in
an effort to 1) reduce downstream maintenance burden, and 2) work
towards solidifying the process of adding new language support to lldb.
Differential Revision: https://reviews.llvm.org/D158470
Thread sanitizer reports a data race in Process.cpp in the usage of
m_process_input_reader. Fix this data race by introducing a mutex
guarding the access to this variable.
Differential Revision: https://reviews.llvm.org/D157648
ThreadSanitizer reports the following issue:
```
Write of size 8 at 0x00010a70abb0 by thread T3 (mutexes: write M0):
#0 lldb_private::ThreadList::Update(lldb_private::ThreadList&) ThreadList.cpp:741 (liblldb.18.0.0git.dylib:arm64+0x5dedf4) (BuildId: 9bced2aafa373580ae9d750d9cf79a8f32000000200000000100000000000e00)
#1 lldb_private::Process::UpdateThreadListIfNeeded() Process.cpp:1212 (liblldb.18.0.0git.dylib:arm64+0x53bbec) (BuildId: 9bced2aafa373580ae9d750d9cf79a8f32000000200000000100000000000e00)
Previous read of size 8 at 0x00010a70abb0 by main thread (mutexes: write M1):
#0 lldb_private::ThreadList::GetMutex() const ThreadList.cpp:785 (liblldb.18.0.0git.dylib:arm64+0x5df138) (BuildId: 9bced2aafa373580ae9d750d9cf79a8f32000000200000000100000000000e00)
#1 lldb_private::ThreadList::DidResume() ThreadList.cpp:656 (liblldb.18.0.0git.dylib:arm64+0x5de5c0) (BuildId: 9bced2aafa373580ae9d750d9cf79a8f32000000200000000100000000000e00)
#2 lldb_private::Process::PrivateResume() Process.cpp:3130 (liblldb.18.0.0git.dylib:arm64+0x53cd7c) (BuildId: 9bced2aafa373580ae9d750d9cf79a8f32000000200000000100000000000e00)
```
Fix this by only using the mutex in ThreadList and removing the one in
process entirely.
Differential Revision: https://reviews.llvm.org/D158034
This patch gets clang-6 building with LLDB. The move from makeArrayRef
to deduction guides in 984b800a036fc61ccb129a8da7592af9cadc94dd is
tripping up clang-6 on Ubuntu 18.04.
Related to issue #64782.
We added support for the GNUstep ObjC runtime in 0b6264738f3d. In order to check if the target process uses
GNUstep we run an expensive symbol lookup in `CreateInstance()`. This turned out to cause a heavy performance
regression for non-GNUstep inferiors.
This patch puts a cheaper check in front, so that the vast majority of requests should return early. This
should fix the symptom for the moment. The conceptual question remains: Why does `LanguageRuntime::FindPlugin`
invoke `create_callback` for each available runtime unconditionally in every `Process::ModulesDidLoad`?
Reviewed By: jasonmolenda, jingham, bulbazord
Differential Revision: https://reviews.llvm.org/D158205
qHostInfo / stop-reply packet / LC_NOTE "addrable bits" can all
specify either a single value for all address masks, or separate
masks for low and high memory addresses.
When the same number of addressing bits are used for all addresses,
we use the "low memory" address masks for everything. (or another
way, if the high address masks are not set, we use the low address
masks with the assumption that all memory is using the same mask --
the most common situation).
I was setting low and high address masks when I had a single value
from these metadata, but that gave the impression that the high
address mask was specified explicitly. After living on the code
a bit, it's clearly better to only set the high address masks when
we have a distinct high address mask value.
This patch is the minor adjustment to behave that way.
I wrote some complicated conditionals for how to handle a partially
specified AddressableBits object in https://reviews.llvm.org/D158041 ,
and how to reuse existing masks if they were set and we had an
unspecified value.
I don't think this logic is the right thing to start
with. Simplify back to the most straightforward
setting, where only the bits that have been specified
are set in the Process.
ConstStrings are super cheap to copy around. It is often more expensive
to pass a pointer and potentially dereference it than just to always copy it.
Differential Revision: https://reviews.llvm.org/D158043
I'm rewriting this for 2 reasons:
1) Although a 1024 char buffer is probably enough space, the error
string may grow beyond that and we could lose some information. Using
StringStream (as we do in the rest of ProcessGDBRemote) seems like a
sensible solution.
2) I am planning on changing `UnixSignals::GetSignalAsCString`,
rewriting things with `llvm::formatv` will make that process easier.
Differential Revision: https://reviews.llvm.org/D158017
The ASTImporter::Imported base method has been made a no-op in
26f72a96559f2acd6799c363f1ca88ef3238c601. So all calls to it from
a base-class are now redundant. The API is now only used to notify
subclasses that an import occurred and not for any other
bookkeeping (which is done in MapImported which we call properly).
Differential Revision: https://reviews.llvm.org/D158172
LLDB doesn't yet have a TypeSystemRust implemented however it is used to debug Rust applications. Most of the types map well enough to Clang types and there are python formatters implemented to display those types reasonably well in a debugger.
However, Rust enums are completely ignored by LLDB as Clang never emits DW_TAG_variant_part inside DW_TAG_structure_type
This diff adds a parser for DW_TAG_variant_part (Rust-only) that creates a matching valid Clang declaration to the Rust enum. As long as there is enough information and all fields have correct offsets synthetic/summary providers can be implemented to display it correctly when debugging Rust code
Differential Revision: https://reviews.llvm.org/D149213
Add support for the `low_mem_addressing_bits` and
`high_mem_addressing_bits` keys in the stop reply packet,
in addition to the existing `addressing_bits`. Same
behavior as in the qHostInfo packet.
Clean up AddressableBits so we don't need to check if
any values have been set in the object before using it
to potentially update the Process address masks.
Differential Revision: https://reviews.llvm.org/D158041
Before the addition of the process "Shadow Listener" you could only have one
Listener observing the Process Broadcaster. That was necessary because fetching the
Process event is what switches the public process state, and for the execution
control logic to be manageable you needed to keep other listeners from causing
this to happen before the main process control engine was ready.
Ismail added the notion of a "ShadowListener" - which allowed you ONE
extra process listener. This patch inverts that setup by designating the
first listener as primary - and giving it priority in fetching events.
Differential Revision: https://reviews.llvm.org/D157556
Before this patch, any time TreeItem is copied in Resize method, its
parent is not updated, which can cause crashes when, for example, thread
window with multiple hierarchy levels is updated. Makes TreeItem
move-only, removes TreeItem's m_delegate extra self-assignment by making
it a pointer, adds code to fix up children's parent on move constructor
and operator=
Patch prepared by NH5pml30
~~~
Huawei RRI, OS Lab
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D157960
The usage of this variable was removed in `4f14c17df70916913d71914343dd4f6c709e218d`.
This is no longer used inside this file. Since the call to
`GetPersistentExpressionStateForLanguage` has side-effects I marked this
NFCI. But there is no good reason we need this here.
Differential Revision: https://reviews.llvm.org/D157992
Some Apple firmware environments store the UUID of the main binary
at a fixed address in low memory. Add that list of addresess to
ProcessMachCore to check for a UUID, and try to load it.
Differential Revision: https://reviews.llvm.org/D157756
On AArch64 systems, we may have different page table setups for
low memory and high memory, and therefore a different number of
bits used for addressing depending on which half of memory the
address is in.
This patch extends the qHostInfo and LC_NOTE "addrable bits" so
that it can specify the number of addressing bits in high memory
and in low memory separately. It builds on the patch I added in
https://reviews.llvm.org/D151292 where Process tracks the separate
address masks, and there is a user setting to set them manually.
Differential Revision: https://reviews.llvm.org/D157667
rdar://113225907
This patch fixes warnings like:
lldb/source/Core/ModuleList.cpp:1086:3: error: 'scoped_lock' may not
intend to support class template argument deduction
[-Werror,-Wctad-maybe-unsupported]
