Prior to this fix, no shared libraries would be loaded for a core file, even if they exist on the current machine. The issue was the DYLDRendezvous would read a DYLDRendezvous::Rendezvous from memory of the process in DYLDRendezvous::Resolve() which would read some ld.so structures as they existed in the middle of a process' lifetime. In core files we see, the DYLDRendezvous::Rendezvous::state would be set to eAdd for running processes. When ProcessELFCore.cpp would load the core file, it would call DynamicLoaderPOSIXDYLD::DidAttach(), which would call the above Rendezvous functions. The issue came when during the DidAttach function it call DYLDRendezvous::GetAction() which would return eNoAction if the DYLDRendezvous::m_current.state was read from memory as eAdd. This caused no shared libraries to be loaded for any ELF core files. We now detect if we have a core file and after reading the DYLDRendezvous::m_current.state from memory we set it to eConsistent, which causes DYLDRendezvous::GetAction() to return the correct action of eTakeSnapshot and shared libraries get loaded.
We also improve the DynamicLoaderPOSIXDYLD class to not try and set any breakpoints to catch shared library loads/unloads when we have a core file, which saves a bit of time.
Differential Revision: https://reviews.llvm.org/D134842
Fix a small thinko in https://reviews.llvm.org/D133534 . Normally
DynamicLoaderDarwinKernels are created via the CreateInstance plugin
method, and that plugin method sets the Process CanJIT to false.
In the above patch, I added a new code path that can call the
DynamicLoaderDarwinKernel ctor directly, without going through
CreateInstance, and CanJIT was not being correctly set for the
process.
rdar://101148552
In https://reviews.llvm.org/D133534 I made a little cleanup
to DynamicLoaderDarwinKernel::CreateInstance and unintentionally
changed the logic. Previously it would not create an instance
if there was a binary given to lldb and it was not a kernel.
With my change, the absence of any binary would also cause it
to not create. So connecting to a kernel without any binaries
would fail.
rdar://100985097
I went over the output of the following mess of a command:
(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel
--xargs -0 cat | aspell list --mode=none --ignore-case | grep -E
'^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' |
aspell pipe -W3 | grep : | cut -d' ' -f2 | less)
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Differential revision: https://reviews.llvm.org/D131122
DynamicLoaderDarwinKernel calls in to PlatformDarwinKernel, and
with my changes in https://reviews.llvm.org/D133534, PlatformDarwinKernel
calls in to DynamicLoaderDarwinKernel. This results in a cmake
dependency if accurately included in the link libraries list.
lldbPluginDynamicLoaderDarwinKernel is specfically for kernel
debugging and is uncommonly linked in to anything except a full
lldb. lldbPluginPlatformMacOSX is any Darwin platform, including
PlatformDarwinKernel, and is referenced a number of time in shell
tests, for instance.
I believe anything linking the darwin kernel DynamicLoader plugin
will already have lldbPluginPlatformMacOSX in its dependency list,
so not explicitly expressing this dependency is safe.
Complete support of the binary-addresses key in the qProcessInfo packet
in ProcessGDBRemote, for detecting if one of the binaries needs to be
handled by a Platform plugin, and can be used to set the Process'
DynamicLoader plugin and the Target's Platform plugin.
Implement this method in PlatformDarwinKernel to recognize a kernel
fileset at that address, find the actual kernel address in the
fileset, set DynamicLoaderDarwinKernel and PlatformDarwinKernel
in the Process/Target; register the kernel address with the dynamic
loader so it will be loaded later during attach.
This patch only addresses the live debug scenario with a gdb remote
serial protocol connection. I'll handle corefiles in a subsequent
patch that builds on this.
Differential Revision: https://reviews.llvm.org/D133534
rdar://98754861
LLVM contains a helpful function for getting the size of a C-style
array: `llvm::array_lengthof`. This is useful prior to C++17, but not as
helpful for C++17 or later: `std::size` already has support for C-style
arrays.
Change call sites to use `std::size` instead.
Differential Revision: https://reviews.llvm.org/D133501
arm64e platforms.
On arm64e-capable Apple platforms, the system libraries are always
arm64e, but applications often are arm64. When a target is created
from file, LLDB recognizes it as an arm64 target, but debugserver will
still (technically correct) report the process as being arm64e. For
consistency, set the target to arm64 here.
rdar://92248684
Differential Revision: https://reviews.llvm.org/D133069
Previously, depending on how you constructed a UUID from data or a
StringRef, an input value of all zeros was valid (e.g. setFromData)
or not (e.g. setFromOptionalData). Since there was no way to tell
which interpretation to use, it was done somewhat inconsistently.
This standardizes the meaning of a UUID of all zeros to Not Valid,
and removes all the Optional methods and their uses, as well as the
static factories that supported them.
Differential Revision: https://reviews.llvm.org/D132191
Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes.
The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const.
Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString:
ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const;
This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result.
The patch:
- Removes the non const GetDirectory() and GetFilename() get accessors
- Adds set accessors to replace the above functions: SetDirectory() and SetFilename().
- Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites
- Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently.
Differential Revision: https://reviews.llvm.org/D130549
The FileSpect APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossibly to control all of the times the FileSpec object is modified so we can clear the cache. This patch modifies the APIs of FileSpec so no one can modify the directory or filename directly by adding set accessors and by removing the get accessors that are non const.
Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString:
ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const;
This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result.
The patch:
- Removes the non const GetDirectory() and GetFilename() get accessors
- Adds set accessors to replace the above functions: SetDirectory() and SetFilename().
- Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites
- Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently.
Differential Revision: https://reviews.llvm.org/D130309
Using invalidated vector iterator is at best a UB and could crash depending on STL implementation.
Fixing via minimal changes to preserve the existing code style.
Coverity warning 1454828 (scan.coverity.com)
Differential Revision: https://reviews.llvm.org/D130312
New glibc versions (since 2.34 or including this
<ed3ce71f5c>
patch) trigger the rendezvous breakpoint after they have already added
some modules to the list. This did not play well with our dynamic
loader plugin which was doing a diff of the the reported modules in the
before (RT_ADD) and after (RT_CONSISTENT) states. Specifically, it
caused us to miss some of the modules.
While I think the old behavior makes more sense, I don't think that lldb
is doing the right thing either, as the documentation states that we
should not be expecting a consistent view in the RT_ADD (and RT_DELETE)
states.
Therefore, this patch changes the lldb algorithm to compare the module
list against the previous consistent snapshot. This fixes the previous
issue, and I believe it is more correct in general. It also reduces the
number of times we are fetching the module info, which should speed up
the debugging of processes with many shared libraries.
The change in RefreshModules ensures we don't broadcast the loaded
notification for the dynamic loader (ld.so) module more than once.
Differential Revision: https://reviews.llvm.org/D128264
The DynamicLoaderPOSIXDYLD::GetStepThroughTrampolinePlan() function was
doing the symbol lookup using the demangled name. This stopped working
with https://reviews.llvm.org/D118814. To get things working again, just
use the mangled name for the lookup instead.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D127999
As it exists today, Host::SystemLog is used exclusively for error
reporting. With the introduction of diagnostic events, we have a better
way of reporting those. Instead of printing directly to stderr, these
messages now get printed to the debugger's error stream (when using the
default event handler). Alternatively, if someone is listening for these
events, they can decide how to display them, for example in the context
of an IDE such as Xcode.
This change also means we no longer write these messages to the system
log on Darwin. As far as I know, nobody is relying on this, but I think
this is something we could add to the diagnostic event mechanism.
Differential revision: https://reviews.llvm.org/D128480
On macOS, a process will be launched with /usr/lib/dyld (the
dynamic linker) and the main binary by the kernel. The
first thing the standalone dyld will do is call into the dyld
in the shared cache image. This patch tracks the transition
between the dyld's at the very beginning of process startup.
In DynamicLoaderMacOS::NotifyBreakpointHit() there are two new
cases handled:
`dyld_image_dyld_moved` which is the launch /usr/lib/dyld indicating
that it is about call into the shared cache dyld ane evict itself.
lldb will remove the notification breakpoint it set, clear the binary
image list entirely, get the notification function pointer value out
of the dyld_all_image_infos struct (which is the notification fptr
in the to-be-run shared-cache dyld) and put an address breakpoint
there.
`dyld_notify_adding` is then called by shared-cache dyld, and we
detect this case by noticing that we have an empty binary image list,
normally impossibe, and treating this as if we'd just started a
process attach/launch.
Differential Revision: https://reviews.llvm.org/D127247
rdar://84222158
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
Greg Clayton