lanza added a comment.
What's the boundaries of the stable API, then? This was a public API that was
removed and broke a plugin I used for vim (and I'll be this isn't the only
case, just I'm maybe the only one who has worked on lldb before whose tool
broke). The author used `threading.Thread(someFunc, (debugger,))` to listen on
a socket for fetch requests from lldb outside of the prompt. Not the most
beautiful of implementations, but it worked for years on top of a promised
public stable API.
As far as I know, the only other ways to do this would be to use the
listener/event forwarding mechanism Greg used to set up the curses based GUI in
`Debugger::HandleProcessEvent` or to write an entire new frontend analogous to
the lldb tool itself. The latter implementation is a couple orders of magnitude
more work to implement for a simple plugin author like this. The former isn't
exposed in the SBAPI.
Maybe the SBAPI needs access to the `Debugger::m_forward_listener_sp` for GUI
based usages? Something like:
class SBForwardEventListener:
// called for process events
def HandleProcessEvent(self, event: lldb.SBEvent):
// called for thread events
def HandleThreadEvent(self, event: lldb.SBEvent):
// called for breakpoint events
def HandleBreakpointEvent(self, event: lldb.SBEvent):
for the developer can invoke
def __lldb_init_module(...):
debugger.RegisterForwardEventListener(MyListener())
and be informed for the same whenever the curses GUI would be.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D93926/new/
https://reviews.llvm.org/D93926
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
