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

Reply via email to