[Lldb-commits] [PATCH] D145136: Add a Debugger interruption mechanism in parallel to the Command Interpreter interruption

Wed Mar 1 18:31:42 PST 2023

jingham created this revision.
jingham added reviewers: labath, JDevlieghere, clayborg, jasonmolenda, bulbazord.
Herald added a project: All.
jingham requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

I put up an RFC for debugger interruption a while back.  This is my version of that RFC.

The implementation is based on the way lldb is often used in UI's (as opposed to the simple use in lldb's command driver).  In those cases, the lldb client often includes a thread running the LLDB command interpreter so that they can provide an "LLDB Console" window where the user can run commands, and then on other threads they call various SB API's that are used to fill the Threads, Locals, etc. windows.

So it seemed the most useful model was to separate interrupting into "Interrupting commands servicing the Console" and "Interrupting work the client is doing on its own behalf."  For instance if the client is filling the Locals view, but then the user issues "continue" in the console, the client would want to interrupt filling the Locals view (e.g. interrupt SBFrame.FindVariables()) so that it can continue right away, but not interrupt the user's "continue" command.  Similarly, if the user types some command that's producing lots of output, they want to interrupt that but not stop whatever work the client was doing at the same time.

Another question is how do we tell "Console" window commands from Client commands?  Since we provide a nice API that packages up the "run a command interpreter" behavior, it seemed reasonable to have commands run by the thread servicing RunCommandInterpreter be the "Interpreter" commands, and all other threads belong to the client.

This is also convenient because we can programmatically determine which flag we should check when we check the interruption, which allows us to provide a unified API for checking whether an interrupt was requested.

Also, the CommandInterpreter does its job Command by Command, so there's a natural boundary on which to take down the interrupt request.  However the client program is really the only agent that can know when it wants to start & stop interruption, so instead of a single InterruptCommand with automatic boundaries, I added explicit raise & lower interrupt flag API's.

One slight ugliness is that we already have SBCommandInterpreter::WasInterrupted().  I could have just left that as the one interface to query for interruption.  But long term, I think it makes more sense to think about this as the Debugger figuring out who to interrupt, so I think an SBDebugger::InterruptRequested API is better.  Even though I can't remove the old API, I still added the new one.

One other detail you will see in the tests.  The current behavior for command interpreter interruption is that if a command is interrupted, we discard the output it has accumulated so far and just return the result "Interrupted..."  That's why I had to set the ImmediateOutput file in the test.  I'm on the fence about this behavior, so I opted not to change it for now.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D145136

Files:
  lldb/include/lldb/API/SBCommandInterpreter.h
  lldb/include/lldb/API/SBDebugger.h
  lldb/include/lldb/Core/Debugger.h
  lldb/include/lldb/Interpreter/CommandInterpreter.h
  lldb/source/API/SBCommandInterpreter.cpp
  lldb/source/API/SBDebugger.cpp
  lldb/source/Commands/CommandObjectTarget.cpp
  lldb/source/Core/Debugger.cpp
  lldb/source/Interpreter/CommandInterpreter.cpp
  lldb/test/API/python_api/was_interrupted/Makefile
  lldb/test/API/python_api/was_interrupted/TestDebuggerInterruption.py
  lldb/test/API/python_api/was_interrupted/interruptible.py
  lldb/test/API/python_api/was_interrupted/main.c

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D145136.501718.patch
Type: text/x-patch
Size: 33078 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20230302/bb9a771a/attachment-0001.bin>