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

[via lldb-commits]

jimingham wrote:



> On Oct 8, 2024, at 9:53 AM, Jim Ingham ***@***.***> wrote:
> 
>> 
>> 
>> 
>>> On Oct 8, 2024, at 2:16 AM, Pavel Labath ***@***.***> wrote:
>>> 
>>> 
>>> Hello all,
>>> 
>>> I'm parachuting in here because we also have a use case that might benefit from something like this. In our case, we want to run some actions (set up data formatters, source paths, etc.) if we find that we're working with a certain kind of binary (which contains information on how to find these). We're currently using a combination of "module loaded" events and stop hooks for this, but neither of them is ideal because the events are asynchronous (so lldb doesn't wait for our processing to finish), and stop hooks happen slightly too late. Ideally, we'd like our hook to run (synchronously) after target creation (or after its executable has been set).
>>> 
>>> I don't really have much to say about the implementation except a note that a one-callback-to-rule-them all might not be ideal for the case where one wants to hook only a certain kind of events. Sure, you can do filtering in the callback, but it means you still get called, which may matter if some of the events occur frequently. This probably doesn't matter for target creation, but it may not be ideal to get called e.g. after every process stop if all you wanted to hook was debugger creation.
>>> 
>> I agree, a one-callback-to-rule-them-all approach would be awkward.  It would be annoying go make everybody that writes targat hooks has to filter out the ones that come when other changes are reported.  But I'm not sure that was what was being suggested.  I understood the question to be between `target stop-hooks` which started life in a very lldb command-line centric view, and a purely script callback based approach.  I think the latter is the better way to go.
>> 
>> But I was still expecting that you would specify at what level you wanted to be called, so you'd do something like:
>> 
>> SBDebugger::SetLifecycleCallback(lldb::eCallbackLevelTarget, "my_module.my_callback_class")
>> 
>> If all the entities we want to watch

[missing phrase]

are contained in the ExecutionContext


>> , we could make the callback take an ExecutionContext that conveys the new info.  So "my_callback_class" would have:
>> 
>> class my_callback_class:
>>     def __call__(self, exe_ctx : SBExecutionContext):
>> 
>> if you registered for Target level callback, the exe_ctx would have the new target (and the debugger if we decide to add that to the ExecutionContext.
>> 
>> However, we should think a bit about that.  Do we also want to observe module loading this way (we don't have another way to do that?).  If so, we can't JUST use the ExecutionContext to convey "what has happened" to the callback.  So we either need to make different classes of callbacks that can receive different "interesting entities".
>> 
>> Jim
>> 
>> 
>>> —
>>> Reply to this email directly, view it on GitHub <https://github.com/llvm/llvm-project/pull/111206#issuecomment-2399309302>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUPVWZ6HHEYMMCQF7KD7FDZ2OPIXAVCNFSM6AAAAABPMR6QDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJZGMYDSMZQGI>.
>>> You are receiving this because you were mentioned.
>>> 
>> 
>> 



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