Move the broadcasting support from GDBRemoteCommunication
to GDBRemoteClientBase since this is where it is actually used. Remove
GDBRemoteCommunication and subclass constructor arguments left over
after Communication cleanup.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D133427
Uses our existing "error string" extension to provide a better
indication of why the launch failed (the client does not make use of the
error yet).
Also, fix the way we obtain the launch error message (make sure we read
the whole message, and skip trailing garbage), and reduce the size of
TestLldbGdbServer by splitting some tests into a separate file.
Differential Revision: https://reviews.llvm.org/D133352
Split the read thread support from Communication into a dedicated
ThreadedCommunication subclass. The read thread support is used only
by a subset of Communication consumers, and it adds a lot of complexity
to the base class. Furthermore, having a dedicated subclass makes it
clear whether a particular consumer needs to account for the possibility
of read thread being running or not.
The modules currently calling `StartReadThread()` are updated to use
`ThreadedCommunication`. The remaining modules use the simplified
`Communication` class.
`SBCommunication` is changed to use `ThreadedCommunication` in order
to avoid changing the public API.
`CommunicationKDP` is updated in order to (hopefully) compile with
the new code. However, I do not have a Darwin box to test it, so I've
limited the changes to the bare minimum.
`GDBRemoteCommunication` is updated to become a `Broadcaster` directly.
Since it does not inherit from `ThreadedCommunication`, its event
support no longer collides with the one used for read thread and can
be implemented cleanly. The support for
`eBroadcastBitReadThreadDidExit` is removed from the code -- since
the read thread was not used, this event was never reported.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D133251
Replace the uses of Communication::Write() with WriteAll() to avoid
partial writes. None of the call sites actually accounted for that
possibility and even if it is unlikely to actually happen, there doesn't
seem to be any real harm from using WriteAll() instead.
Ideally, we'd remove Write() from the public API. However, that would
change the API of SBCommunication. The alternative would be to alias it
to WriteAll().
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D132395
Support using the vCont packet to resume multiple processes
simultaneously when in non-stop mode. The new logic now assumes that:
- actions without a thread-id or with process id of "p-1" apply to all
debugged processes
- actions with a thread-id without process id apply to the current
process (m_continue_process)
As with the other continue packets, it is only possible to resume
processes that are currently stopped (or stop these that are running).
It is unsupported to resume or stop individual threads of a running
process.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128989
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
Enable stdio forwarding when nonstop mode is enabled, and disable it
once it is disabled. This makes it possible to cleanly handle stdio
forwarding while running multiple processes in non-stop mode.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128932
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
Fix the response to `?` packet for threads that are running at the time
(in non-stop mode). The previous code would wrongly send or queue
an empty response for them.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128879
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
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
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
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
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
Fix lldb-server in the non-stop + multiprocess mode to exit on vStopped
only if all processes have exited, rather than when the first one exits.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128639
Implement support for the "t" action that is used to stop a thread.
Normally this action is used only in non-stop mode. However, there's
no technical reason why it couldn't be also used in all-stop mode,
e.g. to express "resume all threads except ..." (`t:...;c`).
While at it, add a more complete test for vCont correctly resuming
a subset of program's threads.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D126983
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
This reverts part of commit 75757c86c6.
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.
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
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
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
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
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
Modify the behavior of the `k` packet to kill all inferiors rather than
just the current one. The specification leaves the exact behavior
of this packet up to the implementation but since vKill is specifically
meant to be used to kill a single process, it seems logical to use `k`
to provide the alternate function of killing all of them.
Move starting stdio forwarding from the "running" response
to the packet handlers that trigger the process to start. This avoids
attempting to start it multiple times when multiple processes are killed
on Linux which implicitly causes LLGS to receive "started" events
for all of them. This is probably also more correct as the ability
to send "O" packets is implied by the continue-like command being issued
(and therefore the client waiting for responses) rather than the start
notification.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D127500
Add a test verifying that plain 'D' packet correctly detaches all
processes.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D127291
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
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
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
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
Include the process identifier in the `T` stop responses when
multiprocess extension is enabled (i.e. prepend it to the thread
identifier). Use the exposed identifier to simplify the fork-and-follow
tests.
The LLDB client accounts for the possible PID since the multiprocess
extension support was added in b601c67192.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D127192
Include the process identifier in W/X stop reasons when multiprocess
extensions are enabled.
The LLDB client does not support process identifiers there at the moment
but it parses packets in such a way that their presence does not cause
any problems.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D127191
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 patch makes use of c++ type checking and scoped enums to make
logging statements shorter and harder to misuse.
Defines like LIBLLDB_LOG_PROCESS are replaces with LLDBLog::Process.
Because it now carries type information we do not need to worry about
matching a specific enum value with the right getter function -- the
compiler will now do that for us.
The main entry point for the logging machinery becomes the GetLog
(template) function, which will obtain the correct Log object based on
the enum type. It achieves this through another template function
(LogChannelFor<T>), which must be specialized for each type, and should
return the appropriate channel object.
This patch also removes the ability to log a message if multiple
categories are enabled simultaneously as it was unused and confusing.
This patch does not actually remove any of the existing interfaces. The
defines and log retrieval functions are left around as wrappers around
the new interfaces. They will be removed in follow-up patch.
Differential Revision: https://reviews.llvm.org/D117490
Implement the qXfer:siginfo:read that is used to read the siginfo_t
(extended signal information) for the current thread. This is currently
implemented on FreeBSD and Linux.
Differential Revision: https://reviews.llvm.org/D117113
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
[NFC] This patch replaces master and slave with primary and secondary
respectively when referring to pseudoterminals/file descriptors.
Reviewed By: clayborg, teemperor
Differential Revision: https://reviews.llvm.org/D113687
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
Use llvm::Optional<uint16_t> instead of int for port number
in UriParser::Parse(), and use llvm::None to indicate missing port
instead of a magic value of -1.
Differential Revision: https://reviews.llvm.org/D112309
Optimize the iterator comparison logic to compare Current.data()
pointers. Use std::tie for assignments from std::pair. Replace
the custom class with a function returning iterator_range.
Differential Revision: https://reviews.llvm.org/D110535
The previous version of the patch did not update the definitions in
conditionally compiled code. This patch includes changes to ARC and
windows targets.
Original commit message was:
These were added to support some mips registers on linux, but linux mips
support has now been removed due.
They are still referenced in the freebds mips implementation, but the
completeness of that implementation is also unknown. All other
architectures just set these fields to zero, which is a cause of
significant bloat in our register info definitions.
Arm also has registers with variable sizes, but they were implemented in
a more gdb-compatible fashion and don't use this feature.
Differential Revision: https://reviews.llvm.org/D110914
This reverts commit 00e704bf08.
This commit should should have updated
llvm/llvm-project/lldb/source/Plugins/ABI/ARC/ABISysV_arc.cpp like the other
architectures.
Michał Górny