jGetLoadedDynamicLibrariesInfos has a mode where it will list
every binary in the process - the load address and filepath from dyld
SPI, and the mach-o header and load commands from a scan by debugserver
for perf reasons. With a large enough number of libraries, creating
that StructuredData representation of all of this, and formatting it
into an ascii string to send up to lldb, can grow debugserver's heap
size too large for some environments.
This patch adds a new report_load_commands:false boolean to the
jGetLoadedDynamicLibrariesInfos packet, where debugserver will now
only report the dyld SPI load address and filepath for all of the
binaries. lldb can then ask for the detailed information on
the process binaries in smaller chunks, and avoid debugserver
having ever growing heap use as the number of binaries inevitably
increases.
This patch also removes a version of jGetLoadedDynamicLibrariesInfos
for pre-iOS 10 and pre-macOS 10.12 systems where we did not use
dyld SPI. We can't back compile to those OS builds any longer
with modern Xcode.
Finally, it removes a requirement in DynamicLoaderMacOS that the
JSON reply from jGetLoadedDynamicLibrariesInfos include the
mod_date field for each binary. This has always been reported as
0 in modern dyld, and is another reason for packet growth in
the reply. debugserver still puts the mod_date field in its replies
for interop with existing lldb's, but we will be able to remove it
the field from debugserver's output after the next release cycle
when this patch has had time to circulate.
I'll add lldb support for requesting the load addresses only
and splitting the request up into chunks in a separate patch.
Differential Revision: https://reviews.llvm.org/D150158
rdar://107848326
Add suport for MASK style watchpoints on AArch64 in debugserver
on Darwin systems, for watching power-of-2 sized memory ranges.
More work needed in lldb before this can be exposed to the user
(because they will often try watching memory ranges that are not
exactly power-of-2 in size/alignment) but this is the first part
of adding that capability.
Differential Revision: https://reviews.llvm.org/D149792
rdar://108233371
Refactor the debugserver watchpiont support in anticipating of
adding support for AArch64 MASK hardware watchpoints to watch
larger regions of memory. debugserver already had support for
handling a request to watch an unaligned region of memory up
to 8 bytes using Byte Address Select watchpoints - it would split
an unaligned watch request into two aligned doublewords that
could be watched with two hardware watchpoints using the BAS
specification.
This patch generalizes that code for properly aligning, and
possibly splitting, a watchpoint request into two hardware watchpoints
to handle any size request. And separates out the specifics
about BAS watchpoints into its own method, so a sibling method
for MASK watchpoints can be dropped in next.
Differential Revision: https://reviews.llvm.org/D149040
rdar://108233371
i386 and armv7 macOS/iOS cannot be built with current Xcode
any longer; we cannot build or test the support code for running
debugserver on these targets. Remove the code.
Differential Revision: https://reviews.llvm.org/D149503
Have debugserver parse the watchpoint flags out of the exception
syndrome register when we get a watchpoint mach exception. Relay
those fields up to lldb in the stop reply packet, if the watchpoint
number was reported by the hardware, use the address from that as
the watchpoint address.
Change how watchpoints are reported to lldb from using the mach
exception data, to using the `reason:watchpoint` and `description:asciihex`
method that lldb-server uses, which can relay the actual trap address
as well as the address of a watched memory region responsible for
the trap, so lldb can step past it.
Have debugserver look for the nearest watchpoint that it has set
when it gets a watchpoint trap, so accesses that are reported as
starting before the watched region are associated with the correct
watchpoint to lldb. Add a test case for this specific issue.
Differential Revision: https://reviews.llvm.org/D147820
rdar://83996471
Some build bots have not been updated to the new minimal CMake version.
Reverting for now and ping the buildbot owners.
This reverts commit 44c6b905f8.
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
Reviewed By: mehdi_amini, MaskRay, ChuanqiXu, to268, thieta, tschuett, phosek, #libunwind, #libc_vendors, #libc, #libc_abi, sivachandra, philnik, zibi
Differential Revision: https://reviews.llvm.org/D144509
The architecture dependent files for debugserver were
built out of their own separate CMakeLists.txt for historical
reasons; it's not necessary any longer. Remove that file
and put them in the main debugserver CMakeLists.txt.
Differential Revision: https://reviews.llvm.org/D145020
rdar://105993317
It's possible for debugserver to attach to a process during the handoff
between /usr/lib/dyld and the dyld in the shared cache. When that
happens, we may end up in a state where there is no dyld in the process
and our debugging session is doomed. To make that scenario a lot less
likely, we can insert a sleep right before attaching after waiting to
find the right pid.
rdar://105513180
Differential Revision: https://reviews.llvm.org/D144311
Prior to setting up logging, we have uses of RNBLogSTDERR and
RNBLogSTDOUT. These macros will dump to STDERR and STDOUT respectively
if debugserver has a tty. Otherwise, it uses _DNBLog, which will do
nothing if a logging function hasn't been set up. For example, if you
specify a log file that cannot be opened for any reason and you don't
have a tty, you have 0 insight into what happened.
rdar://105473133
Differential Revision: https://reviews.llvm.org/D144142
It seems like these were copied from the single-step code and not
updated to match the new flags.
Differential revision: https://reviews.llvm.org/D141816
After an exec, the inferior is a new process and none of these memory
regions are still allocated. Clear them out.
Differential Revision: https://reviews.llvm.org/D140253
The arm64 register context on Darwin has the 29 general purpose
registers, then pc/sp/lr/fp with different field names depending
on compile-time flags. Instead of accessing beyond the end of
the uint64_t[29] array, and upsetting the sanitizers, access those
registers correctly with the correct name.
Fixes a test failure on the ASAN CI bot, currently being
skipped, in TestEarlyProcessLaunch.py.
Differential Revision: https://reviews.llvm.org/D140067
rdar://103359354
The dynamic linker on Darwin, dyld, can provide status of
the process state for a few significant points early on,
most importantly, when libSystem has been initialized and it
is safe to call functions behind the scenes. Pipe this
information up from debugserver to DynamicLoaderMacOS, for
the DynamicLoader::IsFullyInitialized() method, then have
Thread::SafeToCallFunctions use this information. Finally,
for the two utility functions in the AppleObjCRuntimeV2
LanguageRuntime plugin that I was fixing, call this method
before running our utility functions to collect the list of
objc classes registered in the runtime.
User expressions will still be allowed to run any time -
we assume the user knows what they are doing - but these
two additional utility functions that they are unaware of
will be limited by this state.
Differential Revision: https://reviews.llvm.org/D139054
rdar://102436092
can probably make function calls.
Change debugserver's posix_spawn() to spawn an inferior process in
its own process group, so signals from the terminal like control-c
are passed to the inferior process instead of debugserer. In lldb's
own native-host launching, there is a LaunchInfo option
LaunchInSeparateProcessGroup, and this mirrors the most common
setting of that on Darwin systems.
Patch by Alessandro Arzilli <alessandro.arzilli@gmail.com>.
Differential Revision: https://reviews.llvm.org/D128504
Fixes warnings (or errors, if someone injects -Werror in their build system,
which happens in fact with some folks vendoring LLVM too) with Clang 16:
```
+/var/tmp/portage.notmp/portage/sys-devel/llvm-15.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: warning: a function declaration without a prototype
is deprecated in all versions of C [-Wstrict-prototypes]
-/var/tmp/portage.notmp/portage/sys-devel/llvm-14.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: error: a function declaration without a prototype is
deprecated in all versions of C [-Werror,-Wstrict-prototypes]
int main() {return 0;}
^
void
```
Differential Revision: https://reviews.llvm.org/D137503
debugserver parses the Mach-O header & load commands of
binaries; if it does this with a binary whose LC_BUILD
platform enum it does not recognize, it will currently crash.
This patch changes MachProcss::GetPlatformString to return
an optional platform string, and updates the callers to
do the right thing when this optional could not be
provided.
Differential Revision: https://reviews.llvm.org/D136719
rdar://100452994
debugserver is currently using kernel supplied macros,
arm_thread_state64_get_{pc,fp,sp,lr} which can crash on an authorization
failure when the inferior has crashed with an invalid pc value, for
instance. debugserver needs to be resistant to crashing in this
scenario, and we're merely clearing the bits, so do it with a bit
mask operation instead.
Differential Revision: https://reviews.llvm.org/D136620
rdar://98073271
rdar://100663221
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
jGetLoadedDynamicLibrariesInfos normally checks with dyld to find
the list of binaries loaded in the inferior, and getting the filepath,
before trying to parse the Mach-O binary in inferior memory.
This allows for debugserver to parse a Mach-O binary present in memory,
but not yet registered with dyld. This patch also adds some simple
sanity checks that we're reading a Mach-O header before we begin
stepping through load commands, because we won't have the sanity check
of consulting dyld for the list of loaded binaries before parsing.
Also adds a testcase.
[This patch was reverted after causing a testsuite failure on a CI bot;
I haven't been able to repro the failure outside the CI, but I have a
theory that my sanity check on cputype which only matched arm64 and
x86_64 - and the CI machine may have a watch simulator that is still
using i386.]
Differential Revision: https://reviews.llvm.org/D128956
rdar://95737734
jGetLoadedDynamicLibrariesInfos normally checks with dyld to find
the list of binaries loaded in the inferior, and getting the filepath,
before trying to parse the Mach-O binary in inferior memory.
This allows for debugserver to parse a Mach-O binary present in memory,
but not yet registered with dyld. This patch also adds some simple
sanity checks that we're reading a Mach-O header before we begin
stepping through load commands, because we won't have the sanity check
of consulting dyld for the list of loaded binaries before parsing.
Also adds a testcase.
Differential Revision: https://reviews.llvm.org/D128956
rdar://95737734
Michał's change in https://reviews.llvm.org/D127193 did a search &
replace for a pattern that also appears in debugserver, but it
shouldn't be done there.
Fix ThreadStopInfo struct to include the signal number for all events.
Since signo was not included in the details for fork, vfork
and vforkdone stops, the code incidentally referenced the wrong union
member, resulting in wrong signo being sent.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D127193
Report the correct register number (GENERIC_REGNUM_FLAGS) for cpsr. This
fixes TestLldbGdbServer.py on Apple Silicon.
Differential revision: https://reviews.llvm.org/D126076
should not receive as exceptions (some will get converted to BSD
signals instead). This is really the only stable way to ensure that
a Mach exception gets converted to it's equivalent BSD signal. For
programs that rely on BSD signal handlers, this has to happen or you
can't even get the program to invoke the signal handler when under
the debugger.
This builds on a previous solution to this problem which required you
start debugserver with the -U flag. This was not very discoverable
and required lldb be the one to launch debugserver, which is not always
the case.
Differential Revision: https://reviews.llvm.org/D125434
Currently, debugserver has a test to check if it was launched in
translation. The intent was to cover the case where an x86_64
debugserver attempts to control an arm64/arm64e process, returning
an error. However, this check also covers the case where users
are attaching to an x86_64 process, exiting out before attempting
to hand off control to the translated debugserver at
`/Library/Apple/usr/libexec/oah/debugserver`.
This diff delays the debugserver translation check until after
determining whether to hand off control to
`/Library/Apple/usr/libexec/oah/debugserver`. Only when the
process is not translated and thus has not been handed off do we
check if the debugserver is translated, erroring out in that case.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D124814
debugserver does not call thread_set_state when changing xmm/ymm/zmm
register values, so the register contents are never updated. Fix
that. Mark the shell tests which xfail'ed these tests on darwin systems
to xfail them when the system debugserver, they will pass when using
the in-tree debugserver. When this makes it into the installed
system debugservers, we'll remove the xfails.
Differential Revision: https://reviews.llvm.org/D123269
rdar://91258333
rdar://31294382
All uses of JSONGenerator in debugserver would create a JSON text
dump of the object collection, then copy that string into a
binary-escaped string, then send it up to the lldb side or
make a compressed version and send that.
This adds a DumpBinaryEscaped method to JSONGenerator which
does the gdb remote serial protocol binary escaping directly,
and removes the need to pass over the string and have an
additional copy in memory.
Differential Revision: https://reviews.llvm.org/D122882
rdar://91117456
Many callers of SendPacket() in RNBRemote.cpp have a local std::string
object, call c_str() on it to pass a c-string, which is then copied into
a std::string temporary object.
Also free JSONGenerator objects once we've formatted them into
ostringstream and don't need the objects any longer, to reduce max
memory use in debugserver.
Differential Revision: https://reviews.llvm.org/D122848
rdar://91117263
Applied modernize-use-equals-default clang-tidy check over LLDB.
This check is already present in the lldb/.clang-tidy config.
Differential Revision: https://reviews.llvm.org/D121844
Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this
awkward, since the rest of the condition code may also need GNUInstallDirs.
The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward.
Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D117639
