[all-commits] [llvm/llvm-project] bc04d2: [lldb] [llgs] Implement non-stop style stop notifi...

[Michał Górny via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: bc04d240850bab340341eaf3601c5ca996667319
      https://github.com/llvm/llvm-project/commit/bc04d240850bab340341eaf3601c5ca996667319
  Author: Michał Górny <mgorny at moritz.systems>
  Date:   2022-06-21 (Tue, 21 Jun 2022)

  Changed paths:
    M lldb/include/lldb/Utility/StringExtractorGDBRemote.h
    M lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
    M lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
    M lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
    M lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.h
    M lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
    M lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
    M lldb/source/Utility/StringExtractorGDBRemote.cpp
    A lldb/test/API/tools/lldb-server/TestNonStop.py

  Log Message:
  -----------
  [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