Hi Jim,
Thanks for the insight into what's going on. I figured I might be misusing the listener stuff. It would be great if there were a way to register for these kinds of events from the python interface.
For now, the stop-hook will suffice. The only issue that I have is with that is registering the stop hook only works when there is a target loaded:
(lldb) target stop-hook add -o 'voltron update'
error: invalid target
(lldb) file ~/Projects/voltron/test_x64
Current executable set to '~/Projects/voltron/test_x64' (x86_64).
(lldb) target stop-hook add -o 'voltron update'
Stop hook #1 added.
Yes, there is a class of target-related entities that currently can't be created without a real target. This includes stop-hooks but also breakpoints and signal handling behaviors.
At first I thought we should provide some kind of "template Target" that you can prime with breakpoints, stop hooks, signal handling behaviors, etc, and then have those behaviors copied into new targets as they are created. But at the same time I wanted to make it possible to prime these "template Targets" using some predicates to express things like "if the Platform is MacOSX, set these breakpoints, if Linux, these" or again based on architecture. It isn't clear how you would specify this, however, since it would have to be part of the command, say "break set" or "target stop-hook add" etc.
So another way I though of would be to add a m ore general notion of "hooks" that would get triggered by various interesting debugger "life-cycle" events. In this case, we could provide "target created" hooks, and you could add stop hooks & breakpoints, etc, there. This might give an easier way to specify the predicates, either something like:
(lldb) hook add target.create --arch x86_64 --executable-name MyProg --platform-name remote-macosx
Enter Target Create hook code, type DONE when done
hook add process.stop-hook -o "voltron update"
DONE
or another way we have toyed with that would also extend to settings is something like:
(lldb) hook add target[arch=x86_64;exec-name=MyProg;platform-name=remote-macosx].create
Enter Target Create hook code, type DONE when done
hook add process.stop-hook -o "voltron update"
DONE
Note, if we're going to do this, I'd also like to move the target stop-hooks into a general hook mechanism. And you could add "process created/died" "shared library loaded" and "thread created/died" hooks for platforms that track this. Some of these already get published by the event system, for those these "life cycle" hooks would just provide a convenient way to access the events from the command line.
The more I think about it the more I like this life cycle event mechanism over the "template target". It isn't quite as obvious as putting:
break set -n Foo
in your .lldbinit file and have all targets set this breakpoint. But it offers the same functionality while being more general, and it means we can add predicates freely without having to muck up all the commands whose settings might be controlled by the predicates.
Jim
