PT_COREDUMP is a relatively recent addition. Use an #ifdef to skip it
if the underlying system does not support it.
Differential Revision: https://reviews.llvm.org/D111214
This reverts commit 47dd1f6428.
After discussing with Jim Ingham, we agreed to leave the test as-is
so we can catch any CI problems instead of silently skipping the test.
xcodebuild, which is invoked by the apple_simulator_test decorator, may
may return a successful status even if it was unable to run due to the
authorization agent denying it. This causes the TestAppleSimulatorOSType
to run when it shouldn't, and throw an excpection when parsing the JSON
that lists the simulators available. Wrap the json parsing in a
try/except block and if it fails, skip the ttest.
Differential Revision: https://reviews.llvm.org/D109336
Fall back to QEnvironmentHexEncoded if QEnvironment is not supported.
The latter packet is an LLDB extension, while the former is universally
supported.
Add tests for both QEnvironment and QEnvironmentHexEncoded packets,
including both use due to characters that need escaping and fallback
when QEnvironment is not supported.
Differential Revision: https://reviews.llvm.org/D108018
Implement the simpler vRun packet and prefer it over the A packet.
Unlike the latter, it tranmits command-line arguments without redundant
indices and lengths. This also improves GDB compatibility since modern
versions of gdbserver do not implement the A packet at all.
Make qLaunchSuccess not obligatory when using vRun. It is not
implemented by gdbserver, and since vRun returns the stop reason,
we can assume it to be successful.
Differential Revision: https://reviews.llvm.org/D107931
Add two new commands 'platform get-file-permissions' and 'platform
file-exists' for the respective bits of LLDB protocol. Add tests for
them. Fix error handling in GetFilePermissions().
Differential Revision: https://reviews.llvm.org/D107809
Add a new SaveCore() process method that can be used to request a core
dump. This is currently implemented on NetBSD via the PT_DUMPCORE
ptrace(2) request, and enabled via 'savecore' extension.
Protocol-wise, a new qSaveCore packet is introduced. It accepts zero
or more semicolon-separated key:value options, invokes the core dump
and returns a key:value response. Currently the only option supported
is "path-hint", and the return value contains the "path" actually used.
The support for the feature is exposed via qSaveCore qSupported feature.
Differential Revision: https://reviews.llvm.org/D101285
Use hexadecimal numbers rather than decimal in various vFile packets
in order to fix compatibility with gdbserver. This also changes the few
custom LLDB packets -- while technically they do not have to be changed,
it is easier to use the same syntax consistently across LLDB.
Differential Revision: https://reviews.llvm.org/D107475
Following tests fail on Arm/AArch64 randomly with timeouts:
TestMultilineNavigation.py
TestBatchMode.py
TestUnicode.py
TestGdbRemote_vContThreads.py
I am marking them as skipped until we find a away make to pass reliably.
The type field is a signed integer.
(https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html)
However it's not packed in the packet in the way
you might think. For example the type -1 should be:
qMemTags:<addr>,<len>:ffffffff
Instead of:
qMemTags:<addr>,<len>:-1
This change makes lldb-server's parsing more strict
and adds more tests to check that we handle negative types
correctly in lldb and lldb-server.
We only support one tag type value at this point,
for AArch64 MTE, which is positive. So this doesn't change
any of those interactions. It just brings us in line with GDB.
Also check that the test target has MTE. Previously
we just checked that we were AArch64 with a toolchain
that supports MTE.
Finally, update the tag type check for QMemTags to use
the same conversion steps that qMemTags now does.
Using static_cast can invoke UB and though we do do a limit
check to avoid this, I think it's clearer with the new method.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D104914
This is implemented using the QMemTags packet, as specified
by GDB in:
https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#General-Query-Packets
(recall that qMemTags was previously added to read tags)
On receipt of a valid packet lldb-server will:
* align the given address and length to granules
(most of the time lldb will have already done this
but the specification doesn't guarantee it)
* Repeat the supplied tags as many times as needed to cover
the range. (if tags > range we just use as many as needed)
* Call ptrace POKEMTETAGS to write the tags.
The ptrace step will loop just like the tag read does,
until all tags are written or we get an error.
Meaning that if ptrace succeeds it could be a partial write.
So we call it again and if we then get an error, return an error to
lldb.
We are not going to attempt to restore tags after a partial
write followed by an error. This matches the behaviour of the
existing memory writes.
The lldb-server tests have been extended to include read and
write in the same test file. With some updated function names
since "qMemTags" vs "QMemTags" isn't very clear when they're
next to each other.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D105180
This patch adds a helper function to test target architecture is
AArch64 or not. This also tightens isAArch64* helpers by adding an
extra architecture check.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D105483
Support using the extended thread-id syntax with Hg packet to select
a subprocess. This makes it possible to start providing support for
running some of the debugger packets against another subprocesses.
Differential Revision: https://reviews.llvm.org/D100261
This adds memory tag reading using the new "qMemTags"
packet and ptrace on AArch64 Linux.
This new packet is following the one used by GDB.
(https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html)
On AArch64 Linux we use ptrace's PEEKMTETAGS to read
tags and we assume that lldb has already checked that the
memory region actually has tagging enabled.
We do not assume that lldb has expanded the requested range
to granules and expand it again to be sure.
(although lldb will be sending aligned ranges because it happens
to need them client side anyway)
Also we don't assume untagged addresses. So for AArch64 we'll
remove the top byte before using them. (the top byte includes
MTE and other non address data)
To do the ptrace read NativeProcessLinux will ask the native
register context for a memory tag manager based on the
type in the packet. This also gives you the ptrace numbers you need.
(it's called a register context but it also has non register data,
so it saves adding another per platform sub class)
The only supported platform for this is AArch64 Linux and the only
supported tag type is MTE allocation tags. Anything else will
error.
Ptrace can return a partial result but for lldb-server we will
be treating that as an error. To succeed we need to get all the tags
we expect.
(Note that the protocol leaves room for logical tags to be
read via qMemTags but this is not going to be implemented for lldb
at this time.)
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D95601
This feature "memory-tagging+" indicates that lldb-server
supports memory tagging packets. (added in a later patch)
We check HWCAP2_MTE to decide whether to enable this
feature for Linux.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D97282
Add a new feature to process save-core on Darwin systems -- for
lldb to create a user process corefile with only the dirty (modified
memory) pages included. All of the binaries that were used in the
corefile are assumed to still exist on the system for the duration
of the use of the corefile. A new --style option to process save-core
is added, so a full corefile can be requested if portability across
systems, or across time, is needed for this corefile.
debugserver can now identify the dirty pages in a memory region
when queried with qMemoryRegionInfo, and the size of vm pages is
given in qHostInfo.
Create a new "all image infos" LC_NOTE for Mach-O which allows us
to describe all of the binaries that were loaded in the process --
load address, UUID, file path, segment load addresses, and optionally
whether code from the binary was executing on any thread. The old
"read dyld_all_image_infos and then the in-memory Mach-O load
commands to get segment load addresses" no longer works when we
only have dirty memory.
rdar://69670807
Differential Revision: https://reviews.llvm.org/D88387
Remove hardcoded platform list for QPassSignals, qXfer:auxv:read
and qXfer:libraries-svr4:read and instead query the process plugin
via the GetSupportedExtensions() API.
Differential Revision: https://reviews.llvm.org/D101241
Update lldb-server to not use fork or vfork on watchOS and tvOS as these
functions are explicitly marked unavailable there.
llvm-project/lldb/test/API/tools/lldb-server/main.cpp:304:11:
error: 'fork' is unavailable: not available on watchOS
if (fork() == 0)
^
WatchSimulator6.2.sdk/usr/include/unistd.h:447:8: note: 'fork' has been
explicitly marked unavailable here
pid_t fork(void) __WATCHOS_PROHIBITED __TVOS_PROHIBITED;
^
llvm-project/lldb/test/API/tools/lldb-server/main.cpp:307:11:
error: 'vfork' is unavailable: not available on watchOS
if (vfork() == 0)
^
WatchSimulator6.2.sdk/usr/include/unistd.h:602:8: note: 'vfork' has been
explicitly marked unavailable here
pid_t vfork(void) __WATCHOS_PROHIBITED __TVOS_PROHIBITED;
^
Add a NativeDelegate API to pass new processes (forks) to LLGS,
and support detaching them via the 'D' packet. A 'D' packet without
a specific PID detaches all processes, otherwise it detaches either
the specified subprocess or the main process, depending on the passed
PID.
Differential Revision: https://reviews.llvm.org/D100191
Introduce a NativeProcessProtocol API for indicating support for
protocol extensions and enabling them. LLGS calls
GetSupportedExtensions() method on the process factory to determine
which extensions are supported by the plugin. If the future is both
supported by the plugin and reported as supported by the client, LLGS
enables it and reports to the client as supported by the server.
The extension is enabled on the process instance by calling
SetEnabledExtensions() method. This is done after qSupported exchange
(if the debugger is attached to any process), as well as after launching
or attaching to a new inferior.
The patch adds 'fork' extension corresponding to 'fork-events+'
qSupported feature and 'vfork' extension for 'vfork-events+'. Both
features rely on 'multiprocess+' being supported as well.
Differential Revision: https://reviews.llvm.org/D100153
This functionality is used exactly once, and it is trivial to implement
it differently (capture into two distinct variables, and compare for
equality afterwards).
These two functions are doing the same thing, only one of them is
sending the packets immediately and the other "queues" them to be sent
later. The first one is better as in case of errors, the backtrace will
point straight to the place that caused them.
Modify the first method to avoid duplication, and ten standardize on it.
The annotation is now (since the introduction of @apple_simulator_test)
redundant, and the test could theoretically run on lldb-server too (if
it supported darwin hosts).
This patch fixes an issue, where if the thread has a signal blocked when
we try to inject it into the process (via vCont), then instead of
executing straight away, the injected signal will trigger another stop
when the thread unblocks the signal.
As (linux) threads start their life with SIGUSR1 (among others)
disabled, and only enable it during initialization, injecting the signal
during this window did not behave as expected. The fix is to change the
test to ensure the signal gets injected with the signal unblocked.
The simplest way to do this was to write a dedicated inferior for this
test. I also created a new header to factor out the function retrieving
the (os-specific) thread id.
Add a minimal support for the multiprocess extension in lldb-server.
The server indicates support for it via qSupported, and accepts
thread-ids containing a PID. However, it still does not support
debugging more than one inferior, so any other PID value results
in an error.
Differential Revision: https://reviews.llvm.org/D98482
