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

Nathan Lanza via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Thu Jan 7 21:15:47 PST 2021

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(...):

and be informed for the same whenever the curses GUI would be.

  rG LLVM Github Monorepo



More information about the lldb-commits mailing list