A previous commit enabled LLDB to be able to debug a program launched via ld: https://reviews.llvm.org/D108061.
This commit adds the ability to debug a program launched via ld when it happens during an exec into the dynamic loader. There was an issue where after the exec we would locate the rendezvous structure right away but it didn't contain any valid values and we would try to set the dyanamic loader breakpoint at address zero. This patch fixes that and adds a test.
Differential Revision: https://reviews.llvm.org/D125253
This patch moves the platform creation and selection logic into the
per-debugger platform lists. I've tried to keep functional changes to a
minimum -- the main (only) observable difference in this change is that
APIs, which select a platform by name (e.g.,
Debugger::SetCurrentPlatform) will not automatically pick up a platform
associated with another debugger (or no debugger at all).
I've also added several tests for this functionality -- one of the
pleasant consequences of the debugger isolation is that it is now
possible to test the platform selection and creation logic.
This is a product of the discussion at
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>.
Differential Revision: https://reviews.llvm.org/D120810
Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and
MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our
platform.
Binaries are mapped through FileSystem::CreateDataBuffer which returns a
DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer
because every DataBuffer in LLDB is considered to be writable. In order
to use a read-only llvm::MemoryBuffer I had to split our abstraction
around it.
This patch distinguishes between a DataBuffer (read-only) and
WritableDataBuffer (read-write) and updates LLDB to use the appropriate
one.
rdar://74890607
Differential revision: https://reviews.llvm.org/D122856
When opening core files (and also in some other situations) we could end
up with two vdso modules. This could happen because the vdso module is
very special, and over the years, we have accumulated various ways to
load it.
In D10800, we added one mechanism for loading it, which took the form of
a generic load-from-memory capability. Unfortunately loading an elf file
from memory is not possible (because the loader never loads the entire
file), and our attempts to do so were causing crashes. So, in D34352, we
partially reverted D10800 and implemented a custom mechanism specific to
the vdso.
Unfortunately, enough of D10800 remained such that, under the right
circumstances, it could end up loading a second (non-functional) copy of
the vdso module. This happened when the process plugin did not support
the extended MemoryRegionInfo query (added in D22219, to workaround a
different bug), which meant that the loader plugin was not able to
recognise that the linux-vdso.so.1 module (this is how the loader calls
it) is in fact the same as the [vdso] module (the name used in
/proc/$PID/maps) we loaded before. This typically happened in a core
file, as they don't store this kind of information.
This patch fixes the issue by completing the revert of D10800 -- the
memory loading code is removed completely. It also reduces the scope of
the hackaround introduced in D22219 -- it isn't completely sound and is
only relevant for fairly old (but still supported) versions of android.
I added the memory loading logic to the wasm dynamic loader, which has
since appeared and is relying on this feature (it even has a test). As
far as I can tell loading wasm modules from memory is possible and
reliable. MachO memory loading is not affected by this patch, as it uses
a completely different code path.
Since the scenarios/patches I described came without test cases, I have
created two new gdb-client tests cases for them. They're not
particularly readable, but right now, this is the best way we can
simulate the behavior (bugs) of a particular dynamic linker.
Differential Revision: https://reviews.llvm.org/D122660
The call is useless, as any modules loaded there will be removed in
ResolveExecutableModule. Modules will be reloaded again through the
GetLoadedModuleList call in DYLDRendezvous.cpp.
Report warnings and errors through events instead of printing directly
the to the debugger's error stream. By using events, IDEs such as Xcode
can report these issues in the UI instead of having them show up in the
debugger console.
The new diagnostic events are handled by the default event loop. If a
diagnostic is reported while nobody is listening for the new event
types, it is printed directly to the debugger's error stream.
Differential revision: https://reviews.llvm.org/D121511
This patch moves the platform creation and selection logic into the
per-debugger platform lists. I've tried to keep functional changes to a
minimum -- the main (only) observable difference in this change is that
APIs, which select a platform by name (e.g.,
Debugger::SetCurrentPlatform) will not automatically pick up a platform
associated with another debugger (or no debugger at all).
I've also added several tests for this functionality -- one of the
pleasant consequences of the debugger isolation is that it is now
possible to test the platform selection and creation logic.
This is a product of the discussion at
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>.
Differential Revision: https://reviews.llvm.org/D120810
Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.
After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.
This reverts commit ef82063207.
- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat
When debugging a Simulator process on macOS (e.g. the iPhone simulator),
the process will have both a dyld, and a dyld_sim present. The dyld_sim
is an iOS Simulator binary. The dyld is a macOS binary. Both are
MH_DYLINKER filetypes. lldb needs to identify & set a breakpoint in
dyld, so it has to distinguish between these two.
Previously lldb was checking if the inferior target was x86 (indicating
macOS) and the OS of the MH_DYLINKER binary was iOS/watchOS/etc -- if
so, then this is dyld_sim and we should ignore it. Now with arm64
macOS systems, this check was invalid, and we would set our breakpoint
for new binaries being loaded in dyld_sim, causing binary loading to
be missed by lldb.
This patch uses the Target's ArchSpec triple environment, to see if
this process is a simulator process. If this is a Simulator process,
then we only recognize a MH_DYLINKER binary with OS type macOS as
being dyld.
This patch also removes some code that handled pre-2016 era debugservers
which didn't give us the OS type for each binary. This was only being
used on macOS, where we don't need to handle the presence of very old
debugservers.
Differential Revision: https://reviews.llvm.org/D115001
rdar://85907839
There is no reason why this function should be returning a ConstString.
While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.
I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.
Differential Revision: https://reviews.llvm.org/D111877
When DynamicLoaderMacOS::SetNotificationBreakpoint sets the breakpoint
for new binaries being loaded/unloaded, it limits the scope of that
breakpoint to just dyld, so we don't re-evaluate the breakpoint for
every new binary loaded. I wrote this to get the module's ObjectFile
FileSpec in an earlier change, but this is not correct. If lldb
is debugging a remote system, and it had to read dyld out of memory
from the remote system, it will have no FileSpec on the lldb debugger
host. We need to grab the Module's FileSpec, which in this case is
actually falling back to the PlatformFileSpec, the binary path on the
target system.
rdar://84199646
When rebase_exec=true in DidAttach(), all modules are loaded
before the rendezvous breakpoint is set, which means the
LoadInterpreterModule() method is not called and m_interpreter_module
is not initialized.
This causes the very first rendezvous breakpoint hit with
m_initial_modules_added=false to accidentally unload the
module_sp that corresponds to the dynamic loader.
This bug (introduced in D92187) was causing the rendezvous
mechanism to not work in Android 28. The mechanism works
fine on older/newer versions of Android.
Test: Verified rendezvous on Android 28 and 29
Test: Added dlopen test
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D109797
In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.
Differential Revision: https://reviews.llvm.org/D109600
In macOS 12, the symbol name for the dyld_all_image_infos struct
in dyld has a namespace qualifier. Search for it without qualification,
then with qualification when doing a by-name search. (lldb will
only search for it by name when loading a user process Mach-O corefile)
rdar://76270013
This converts a default constructor's member initializers into C++11
default member initializers. This patch was automatically generated with
clang-tidy and the modernize-use-default-member-init check.
$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix
This is a mass-refactoring patch and this commit will be added to
.git-blame-ignore-revs.
Differential revision: https://reviews.llvm.org/D103483
The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D103084
Instead of looking up a symbol and reducing it to an addr_t to set
a breakpoint, set the breakpoint on the function name directly.
The old Mac OS X dynamic loader plugin worked in terms of addresses
and I incorrectly emulated that here when I wrote this newer one.
Differential Revision: https://reviews.llvm.org/D100931
Commiting this patch for Augusto Noronha who is getting set
up still.
This patch changes Target::ReadMemory so the default behavior
when a read is in a Section that is read-only is to fetch the
data from the local binary image, instead of reading it from
memory. Update all callers to use their old preferences
(the old prefer_file_cache bool) using the new API; we should
revisit these calls and see if they really intend to read
live memory, or if reading from a read-only Section would be
equivalent and important for performance-sensitive cases.
rdar://30634422
Differential revision: https://reviews.llvm.org/D100338
Fill out ProcessMachCore::DoLoadCore to handle LC_NOTE hints with
a UUID or with a UUID+address, and load the binary at the specified
offset correctly. Add tests for all four combinations. Change
DynamicLoaderStatic to not re-set a Section's load address in the
Target if it's already been specified.
Differential Revision: https://reviews.llvm.org/D99571
rdar://51490545
On Darwin based systems, lldb will get notified by dyld before it itself
finished initializing, at which point it's not safe to call certain APIs
or SPIs. Add a method to the DynamicLoader to query that.
Differential revision: https://reviews.llvm.org/D99314
This issue was introduced in https://reviews.llvm.org/D92187.
The guard I'm changing were is supposed to act when linux is loading the linker for the second time (due to differences in paths like symlinks).
This is done by checking `module_sp != m_interpreter_module.lock()` however this will be true when `m_interpreter_module` wasn't initialized, making linux unload the linker module (the most visible result here is that lldb will stop getting notified about new modules loaded by the process, because it can't set the rendezvous breakpoint again after the stepping over it once).
The `m_interpreter_module` is not getting initialize when it goes through this path: dbfdb139f7/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp (L332), which happens when lldb was able to read the address from the dynamic section of the executable.
What I'm not sure about though, is if when we go through this path if we still load the linker twice on linux. If that's the case then it means we need to somehow set the m_interpreter_module instead of the fix I provide here. I've only tested this on Android.
Differential Revision: https://reviews.llvm.org/D96637
The comment for ValueType claims that all values <1 are errors, but
not all switch statements take this into account. This patch
introduces an explicit Error case and deletes all default: cases, so
we get warned about incomplete switch coverage.
https://reviews.llvm.org/D96537
Replace uses of GetModuleAtIndexUnlocked and
GetModulePointerAtIndexUnlocked with the ModuleIterable and
ModuleIterableNoLocking where applicable.
Differential revision: https://reviews.llvm.org/D94271
Fix the POSIX-DYLD plugin to update the cached executable path after
attaching. Previously, the path was cached in DYLDRendezvous
constructor and not updated afterwards. This meant that if LLDB was
attaching to a process (e.g. via connecting to lldb-server), the code
stored the empty path before DidAttach() resolved it. The fix updates
the cached path in DidAttach().
This fixes a new instance of https://llvm.org/pr17880
Differential Revision: https://reviews.llvm.org/D92264
Explicitly consider the libraries reported on the initial rendezvous
breakpoint hit added. This is necessary on FreeBSD since the dynamic
loader issues only a single 'consistent' state rendezvous breakpoint hit
for all the libraries present in DT_NEEDED. It is also helpful on Linux
where it ensures that ld-linux is considered loaded as well
as the shared system libraries reported afterwards.
Reenable memory maps on FreeBSD since this fixed the issue triggered
by them.
Differential Revision: https://reviews.llvm.org/D92187
Explicitly consider the libraries reported on the initial eTakeSnapshot
action added, through adding them to the added soentry list
in DYLDRendezvous::SaveSOEntriesFromRemote(). This is necessary
on FreeBSD since the dynamic loader issues only a single 'consistent'
state rendezvous breakpoint hit for all the libraries present
in DT_NEEDED (while Linux issues an added-consistent event pair).
Reenable memory maps on FreeBSD since this fixed the issue triggered
by them.
Differential Revision: https://reviews.llvm.org/D92187
This is a polymorphic class, copying it is a bad idea.
This was not a problem because most classes inheriting from it were
deleting their copy operations themselves. However, this enables us to
delete those explicit deletions, and ensure noone forgets to add them in
the future.
lldb's PlatforDarwinKernel scans the local filesystem (well known
locations, plus user-specified directories) for kernels and kexts
when doing kernel debugging, and loads them automatically. Sometimes
kernel developers want to debug with *only* a dSYM, in which case they
give lldb the DWARF binary + the dSYM as a binary and symbol file.
This patch adds code to lldb to do this automatically if that's the
best thing lldb can find.
A few other bits of cleanup in PlatformDarwinKernel that I undertook
at the same time:
1. Remove the 'platform.plugin.darwin-kernel.search-locally-for-kexts'
setting. When I added the local filesystem index at start of kernel
debugging, I thought people might object to the cost of the search
and want a way to disable it. No one has.
2. Change the behavior of
'plugin.dynamic-loader.darwin-kernel.load-kexts' setting so it does
not disable the local filesystem scan, or use of the local filesystem
binaries.
3. PlatformDarwinKernel::GetSharedModule into GetSharedModuleKext and
GetSharedModuleKernel for easier readability & maintenance.
4. Added accounting of .dSYM.yaa files (an archive format akin to tar)
that I come across during the scan. I'm not using these for now; it
would be very expensive to expand the archives & see if the UUID matches
what I'm searching for.
<rdar://problem/69774993>
Differential Revision: https://reviews.llvm.org/D88632
Summary:
When we try to find the executable module for our target we don't check
if we already have an executable module set. This causes that when debugging
a program that dlopens another executable, LLDB will take that other executable
as the new executable of the target (which causes that future launches of the
target will launch the dlopen'd executable instead of the original executable).
This just adds a check that we only set the executable when we haven't already
found one.
Fixes rdar://63443099
Reviewers: jasonmolenda, jingham, teemperor
Reviewed By: jasonmolenda, teemperor
Subscribers: jingham, JDevlieghere
Differential Revision: https://reviews.llvm.org/D80724
Summary:
On macOS 11, the libraries that have been integrated in the system
shared cache are not present on the filesystem anymore. LLDB was
using those files to get access to the symbols of those libraries.
LLDB can get the images from the target process memory though.
This has 2 consequences:
- LLDB cannot load the images before the process starts, reporting
an error if someone tries to break on a system symbol.
- Loading the symbols by downloading the data from the inferior
is super slow. It takes tens of seconds at the start of the
debug session to populate the Module list.
To fix this, we can use the library images LLDB has in its own
mapping of the shared cache. Shared cache images are somewhat
special as their LINKEDIT segment is moved to the end of the cache
and thus the images are not contiguous in memory. All of this can
hidden in ObjectFileMachO.
This patch fixes a number of test failures on macOS 11 due to the
first problem described above and adds some specific unittesting
for the new SharedCache Host utilities.
Reviewers: jasonmolenda, labath
Subscribers: llvm-commits, lldb-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D83023
