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

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added a comment.

In D93926#2486013 <https://reviews.llvm.org/D93926#2486013>, @lanza wrote:

> 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. 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.

The debugger variable is still present in the lldb namespace, it's `None` instead of a default constructed debugger, so I would argue that this is not an API breaking change. It has always been documented that those variables are only valid in the interactive script interpreter (https://lldb.llvm.org/use/python-reference.html#embedded-python-interpreter) so it's also not really a policy change. I totally understand how annoying it is that this breaks things (I had to fix incorrect uses myself, such as in the crashlog/symbolication script) but I think it's worth it because it prevents accidental misuse.

> 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.

I'm not sure I understand how this is a problem for the event listener. Why can't you save the debugger in `__lldb_init_module` and start the event listening thread from there?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93926/new/

https://reviews.llvm.org/D93926