[Lldb-commits] [PATCH] D93926: [lldb] Don't remove the lldb.debugger var after exiting the interpreter

[Nathan Lanza via Phabricator via lldb-commits]

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