[Lldb-commits] [lldb] Add SBDebugger:: AddNotificationCallback API (PR #111206)

[Pavel Labath via lldb-commits]

labath wrote:

(This is in reply to Jim's comment [here](https://github.com/llvm/llvm-project/pull/111206#issuecomment-2400376223). I can't quote it, because github garbles it beyond recognition, probably because it was sent by email :/)

You're right, I have misunderstood the intention. The thing that threw me off was the discussion of about the callback signature (which still looks like it wants to be universal). Given that, I'd like to agree with what you said in the last part of your email -- I think it'd be better for the callback signatures to not be universal as well (no one-signature-to-rule-them-all). Here are my reasons for that:
- we sidestep the "should execution context contain a debugger" question -- the debugger callback type can just take a debugger argument, and that's it. A thread callback type can take an SBThread instead of getting an SBExecutionContext and wondering what's inside it.
- we sidestep the "what is the scope of lower-level callback types" question -- it's clear that debugger lifetime callbacks have to be global, but for example, I think it would be reasonable to have e.g. target creation callbacks scoped to the debugger they are being created in (so you can monitor targets in one debugger but not interfere with other debuggers you possibly know nothing about). With the current design we're basically committing to global callbacks, but with the other one, we leave the option open.
- we can pass event-specific data to the callbacks. For example, for my use case, the ideal event type would be "module got added to a target" (basically, a synchronous version of (eBroadcastBitModulesLoaded) or "target's executable module has changed". Fitting that into a universal callback type would be very tricky.

If we do this right, I don't believe this should result in a lot of duplicated code, as we could write (template?) code to handle the (de)registration in a generic way.

https://github.com/llvm/llvm-project/pull/111206