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