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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
