[lldb] Use SmallVector for handling register data

Previously lldb was using arrays of size kMaxRegisterByteSize to handle
registers. This was set to 256 because the largest possible register
we supp

[lldb] Use SmallVector for handling register data

Previously lldb was using arrays of size kMaxRegisterByteSize to handle
registers. This was set to 256 because the largest possible register
we support is Arm's scalable vectors (SVE) which can be up to 256 bytes long.

This means for most operations aside from SVE, we're wasting 192 bytes
of it. Which is ok given that we don't have to pay the cost of a heap
alocation and 256 bytes isn't all that much overall.

With the introduction of the Arm Scalable Matrix extension there is a new
array storage register, ZA. This register is essentially a square made up of
SVE vectors. Therefore ZA could be up to 64kb in size.

https://developer.arm.com/documentation/ddi0616/latest/

"The Effective Streaming SVE vector length, SVL, is a power of two in the range 128 to 2048 bits inclusive."

"The ZA storage is architectural register state consisting of a two-dimensional ZA array of [SVLB × SVLB] bytes."

99% of operations will never touch ZA and making every stack frame 64kb+ just
for that slim chance is a bad idea.

Instead I'm switching register handling to use SmallVector with a stack allocation
size of kTypicalRegisterByteSize. kMaxRegisterByteSize will be used in places
where we can't predict the size of register we're reading (in the GDB remote client).

The result is that the 99% of small register operations can use the stack
as before and the actual ZA operations will move to the heap as needed.

I tested this by first working out -wframe-larger-than values for all the
libraries using the arrays previously. With this change I was able to increase
kMaxRegisterByteSize to 256*256 without hitting those limits. With the
exception of the GDB server which needs to use a max size buffer.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D153626

show more ...

[lldb-server/linux] Use waitpid(-1) to collect inferior events

This is a follow-up to D116372, which had a rather unfortunate side
effect of making the processing of a single SIGCHLD quadratic in th

[lldb-server/linux] Use waitpid(-1) to collect inferior events

This is a follow-up to D116372, which had a rather unfortunate side
effect of making the processing of a single SIGCHLD quadratic in the
number of threads -- which does not matter for simple applications, but
can get really bad for applications with thousands of threads.

This patch fixes the problem by implementing the other possibility
mentioned in the first patch -- doing waitpid(-1) centrally and then
routing the events to the correct process instance. The "uncollected"
threads are held in the process factory class -- which I've renamed to
Manager for this purpose, as it now does more than creating processes.

Differential Revision: https://reviews.llvm.org/D146977

show more ...

[lldb] [llgs] Fix disabling non-stop mode

Stop all processes and clear notification queues when disabling non-stop
mode. Ensure that no stop notifications are sent for processes stopped
due to the

[lldb] [llgs] Fix disabling non-stop mode

Stop all processes and clear notification queues when disabling non-stop
mode. Ensure that no stop notifications are sent for processes stopped
due to the mode switch.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128893

show more ...

[lldb] [llgs] Send process output asynchronously in non-stop mode

Introduce a new %Stdio notification category and use it to send process
output asynchronously when running in non-stop mode. This i

[lldb] [llgs] Send process output asynchronously in non-stop mode

Introduce a new %Stdio notification category and use it to send process
output asynchronously when running in non-stop mode. This is an LLDB
extension since GDB does not use the 'O' packet for process output,
just for replies to 'qRcmd' packets.

Using the async notification mechanism implies that only the first
output packet is sent immediately to the client. The client needs
to request subsequent notifications (if any) using the new vStdio packet
(that works pretty much like vStopped for the Stop notification queue).

The packet handler in lldb-server tests is updated to handle the async
stdio packets in addition to the regular O packets. However, due
to the implications noted above, it can only handle the first output
packet sent by the server. Subsequent packets need to be explicitly
requested via vStdio.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128849

show more ...

Reland "[lldb] [llgs] Fix multi-resume bugs with nonstop mode"

Improve handling of multiple successive continue packets in non-stop
mode. More specifically:

1. Explicitly send error response (inst

Reland "[lldb] [llgs] Fix multi-resume bugs with nonstop mode"

Improve handling of multiple successive continue packets in non-stop
mode. More specifically:

1. Explicitly send error response (instead of crashing on assertion)
if the user attempts to resume the same process twice. Since we
do not support thread-level non-stop mode, one needs to always stop
the process explicitly before resuming another thread set.

2. Actually stop the process if "vCont;t" is delivered to a running
process. Similarly, we only support stopping all the running threads
simultaneously (via -1) and return an error in any other case.

With this patch, running multiple processes simultaneously is still
unsupported. The patch also employs a hack to avoid enabling stdio
forwarding on "vCont;t" packet. Both of these issues are addressed
by followup patches.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128710

show more ...

Revert "[lldb] [llgs] Fix multi-resume bugs with nonstop mode"

This reverts commit f8605da8758fbae16410e4ed5493a39429fd73ec.
This is causing buildbot failures and now I see that I have not updated
t

Revert "[lldb] [llgs] Fix multi-resume bugs with nonstop mode"

This reverts commit f8605da8758fbae16410e4ed5493a39429fd73ec.
This is causing buildbot failures and now I see that I have not updated
the tests to use "stop" instead of "trap".

show more ...

[lldb] [llgs] Fix multi-resume bugs with nonstop mode

Improve handling of multiple successive continue packets in non-stop
mode. More specifically:

1. Explicitly send error response (instead of cr

[lldb] [llgs] Fix multi-resume bugs with nonstop mode

Improve handling of multiple successive continue packets in non-stop
mode. More specifically:

1. Explicitly send error response (instead of crashing on assertion)
if the user attempts to resume the same process twice. Since we
do not support thread-level non-stop mode, one needs to always stop
the process explicitly before resuming another thread set.

2. Actually stop the process if "vCont;t" is delivered to a running
process. Similarly, we only support stopping all the running threads
simultaneously (via -1) and return an error in any other case.

With this patch, running multiple processes simultaneously is still
unsupported. The patch also employs a hack to avoid enabling stdio
forwarding on "vCont;t" packet. Both of these issues are addressed
by followup patches.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128710

show more ...

[lldb] [llgs] Remove not-really-used m_inferior_prev_state

Remove m_inferior_prev_state that's not suitable for multiprocess
debugging and that does not seem to be really used at all.

The only use

[lldb] [llgs] Remove not-really-used m_inferior_prev_state

Remove m_inferior_prev_state that's not suitable for multiprocess
debugging and that does not seem to be really used at all.

The only use of the variable right now is to "prevent" sending the stop
reason after attach/launch. However, this code is never actually run
since none of the process plugins actually use eStateLaunching or
eStateAttaching. Through adding an assert, I've confirmed that it's
never hit in any of the LLDB tests or while attaching/launching debugged
process via lldb-server and via lldb CLI.

Differential Revision: https://reviews.llvm.org/D128878
Sponsored by: The FreeBSD Foundation

show more ...

[lldb] [llgs] Convert m_debugged_processes into a map of structs

Convert the m_debugged_processes map from NativeProcessProtocol pointers
to structs, and combine the additional set(s) holding the ad

[lldb] [llgs] Convert m_debugged_processes into a map of structs

Convert the m_debugged_processes map from NativeProcessProtocol pointers
to structs, and combine the additional set(s) holding the additional
process properties into a flag field inside this struct. This is
desirable since there are more properties to come and having a single
structure with all information should be cleaner and more efficient than
using multiple sets for that.

Suggested by Pavel Labath in D128893.

Differential Revision: https://reviews.llvm.org/D129652

show more ...

Reland "[lldb] [llgs] Support multiprocess in qfThreadInfo"

Now preserving the non-standard behavior of returning "OK" response
when there is no debugged process.

Sponsored by: The FreeBSD Foundati

Reland "[lldb] [llgs] Support multiprocess in qfThreadInfo"

Now preserving the non-standard behavior of returning "OK" response
when there is no debugged process.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128152

show more ...

Revert "[lldb] [llgs] Support multiprocess in qfThreadInfo"

This reverts part of commit 75757c86c695a6b4695458343637b3c4fe86def6.
It broke the following test:

commands/target/auto-install-main-ex

Revert "[lldb] [llgs] Support multiprocess in qfThreadInfo"

This reverts part of commit 75757c86c695a6b4695458343637b3c4fe86def6.
It broke the following test:

commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py

I need more time to figure it out, so I'm reverting the code changes
and marking the tests depending on them xfail.

show more ...

[lldb] [llgs] Introduce an AppendThreadIDToResponse() helper

Introduce a helper function to append GDB Remote Serial Protocol "thread
IDs", with optional PID in multiprocess mode.

Sponsored by: The

[lldb] [llgs] Introduce an AppendThreadIDToResponse() helper

Introduce a helper function to append GDB Remote Serial Protocol "thread
IDs", with optional PID in multiprocess mode.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128324

show more ...

[lldb] [llgs] Implement the 'T' packet

Implement the 'T' packet that is used to verify whether the specified
thread belongs to the debugged processes.

Sponsored by: The FreeBSD Foundation
Different

[lldb] [llgs] Implement the 'T' packet

Implement the 'T' packet that is used to verify whether the specified
thread belongs to the debugged processes.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128170

show more ...

[lldb] [llgs] Support multiprocess in qfThreadInfo

Update the `qfThreadInfo` handler to report threads of all debugged
processes and include PIDs when in multiprocess mode.

Sponsored by: The FreeBS

[lldb] [llgs] Support multiprocess in qfThreadInfo

Update the `qfThreadInfo` handler to report threads of all debugged
processes and include PIDs when in multiprocess mode.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128152

show more ...

[lldb] [llgs] Support resuming one process with PID!=current via vCont

Extend vCont function to support resuming a process with an arbitrary
PID, that could be different than the one selected via Hc

[lldb] [llgs] Support resuming one process with PID!=current via vCont

Extend vCont function to support resuming a process with an arbitrary
PID, that could be different than the one selected via Hc (or no process
at all may be selected). Resuming more than one process simultaneously
is not supported yet.

Remove the ReadTid() method that was only used by Handle_vCont(),
and furthermore it was wrongly using m_current_process rather than
m_continue_process.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D127862

show more ...

[lldb] [llgs] Implement the vKill packet

Implement the support for the vKill packet. This is the modern packet
used by the GDB Remote Serial Protocol to kill one of the debugged
processes. Unlike

[lldb] [llgs] Implement the vKill packet

Implement the support for the vKill packet. This is the modern packet
used by the GDB Remote Serial Protocol to kill one of the debugged
processes. Unlike the `k` packet, it has well-defined semantics.

The `vKill` packet takes the PID of the process to kill, and always
replies with an `OK` reply (rather than the exit status, as LLGS does
for `k` packets at the moment). Additionally, unlike the `k` packet
it does not cause the connection to be terminated once the last process
is killed — the client needs to close it explicitly.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D127667

show more ...

[lldb] [llgs] Implement non-stop style stop notification packets

Implement the support for %Stop asynchronous notification packet format
in LLGS. This does not implement full support for non-stop m

[lldb] [llgs] Implement non-stop style stop notification packets

Implement the support for %Stop asynchronous notification packet format
in LLGS. This does not implement full support for non-stop mode for
threaded programs -- process plugins continue stopping all threads
on every event. However, it will be used to implement asynchronous
events in multiprocess debugging.

The non-stop protocol is enabled using QNonStop packet. When it is
enabled, the server uses notification protocol instead of regular stop
replies. Since all threads are always stopped, notifications are always
generated for all active threads and copied into stop notification
queue.

If the queue was empty, the initial asynchronous %Stop notification
is sent to the client immediately. The client needs to (eventually)
acknowledge the notification by sending the vStopped packet, in which
case it is popped from the queue and the stop reason for the next thread
is reported. This continues until notification queue is empty again,
in which case an OK reply is sent.

Asychronous notifications are also used for vAttach results and program
exits. The `?` packet uses a hybrid approach -- it returns the first
stop reason synchronously, and exposes the stop reasons for remaining
threads via vStopped queue.

The change includes a test case for a program generating a segfault
on 3 threads. The server is expected to generate a stop notification
for the segfaulting thread, along with the notifications for the other
running threads (with "no stop reason"). This verifies that the stop
reasons are correctly reported for all threads, and that notification
queue works.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D125575

show more ...

[lldb] [llgs] Refactor SendStopReasonForState for multiprocess

Refactor GDBRemoteCommunicationServerLLGS::SendStopReasonForState()
to accept process as an argument rather than hardcoding
m_current_p

[lldb] [llgs] Refactor SendStopReasonForState for multiprocess

Refactor GDBRemoteCommunicationServerLLGS::SendStopReasonForState()
to accept process as an argument rather than hardcoding
m_current_process, in order to make it work correctly for multiprocess
scenarios.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D127497

show more ...

[lldb] [llgs] Refactor SendStopReplyPacketForThread for multiprocess

Refactor SendStopReplyPacketForThread() to accept process instance
as a parameter rather than use m_current_process. This future

[lldb] [llgs] Refactor SendStopReplyPacketForThread for multiprocess

Refactor SendStopReplyPacketForThread() to accept process instance
as a parameter rather than use m_current_process. This future-proofs
it for multiprocess support.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D127289

show more ...

[lldb] Fix modernize-use-override warnings (NFC)

Fix modernize-use-override warnings. Because this check is listed in
LLDB's top level .clang-tidy configuration, the check is enabled by
default and

[lldb] Fix modernize-use-override warnings (NFC)

Fix modernize-use-override warnings. Because this check is listed in
LLDB's top level .clang-tidy configuration, the check is enabled by
default and the resulting warnings show up in my editor.

I've audited the modified lines. This is not a blind change.

show more ...

[lldb/gdb-remote] Ignore spurious ACK packets

Although I cannot find any mention of this in the specification, both
gdb and lldb agree on sending an initial + packet after establishing the
connectio

[lldb/gdb-remote] Ignore spurious ACK packets

Although I cannot find any mention of this in the specification, both
gdb and lldb agree on sending an initial + packet after establishing the
connection.

OTOH, gdbserver and lldb-server behavior is subtly different. While
lldb-server *expects* the initial ack, and drops the connection if it is
not received, gdbserver will just ignore a spurious ack at _any_ point
in the connection.

This patch changes lldb's behavior to match that of gdb. An ACK packet
is ignored at any point in the connection (except when expecting an ACK
packet, of course). This is inline with the "be strict in what you
generate, and lenient in what you accept" philosophy, and also enables
us to remove some special cases from the server code. I've extended the
same handling to NAK (-) packets, mainly because I don't see a reason to
treat them differently here.

(The background here is that we had a stub which was sending spurious
+ packets. This bug has since been fixed, but I think this change makes
sense nonetheless.)

Differential Revision: https://reviews.llvm.org/D114520

show more ...

[lldb] [lldb-gdbserver] Unify listen/connect code to use ConnectionFileDescriptor

Unify the listen and connect code inside lldb-server to use
ConnectionFileDescriptor uniformly rather than a mix of

[lldb] [lldb-gdbserver] Unify listen/connect code to use ConnectionFileDescriptor

Unify the listen and connect code inside lldb-server to use
ConnectionFileDescriptor uniformly rather than a mix of it and Acceptor.
This involves:

- adding a function to map legacy values of host:port parameter
(including legacy server URLs) into CFD-style URLs

- adding a callback to return "local socket id" (i.e. UNIX socket path
or TCP port number) between listen() and accept() calls in CFD

- adding a "unix-abstract-accept" scheme to CFD

As an additional advantage, this permits lldb-server to accept any URL
known to CFD including the new serial:// scheme. Effectively,
lldb-server can now listen on the serial port. Tests for connecting
over a pty are added to test that.

Differential Revision: https://reviews.llvm.org/D111964

show more ...

[lldb] [gdb-remote] Implement the vRun packet

Implement the simpler vRun packet and prefer it over the A packet.
Unlike the latter, it tranmits command-line arguments without redundant
indices and l

[lldb] [gdb-remote] Implement the vRun packet

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

show more ...

[lldb] [llgs server] Support creating core dumps on NetBSD

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
p

[lldb] [llgs server] Support creating core dumps on NetBSD

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

show more ...

[lldb][AArch64] Add memory tag writing to lldb-server

This is implemented using the QMemTags packet, as specified
by GDB in:
https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.h

[lldb][AArch64] Add memory tag writing to lldb-server

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

show more ...