stap should support some kind of probe syntax that means essentially probe process(target()).function("func") etc. so when the user says stap -c pgm xxx.stp and xxx.stp contains a probe definition like the above, the stap-generated module registers the probe using pgm's pid, after the staprun child execs pgm. Kprobes are registered before the exec, but uprobes registration must wait 'til the process is running the right program. I guess this means registering a utrace engine, with exec callback, during systemtap_module_init() and having the exec callback register the uprobes.
Actually, the target process execs twice: staprun execs /bin/sh, then /bin/sh execs the target program. E.g., --- target2.stp --- global targets probe begin { printf("target() = %d\n", target()); targets[target()] = 1 } probe process.create { if (pid() in targets) { printf("%d forks %d\n", pid(), new_pid); targets[new_pid] = 1 } } probe process.exec { if (pid() in targets) printf("%d execs %s\n", pid(), filename) } --- $ stap -c /bin/true target2.stp target() = 6517 6517 execs /bin/sh 6517 execs /bin/true $
I've just started working on a related, yet different, feature. It is possible that the feature this bug talks about could fall out from that work or be a small addition to it. I'm work on providing the ability to do something like: probe process("/bin/program_of_interest").create { # do something here... } probe process("/bin/program_of_interest").exit { # do something here... } (I'm undecided on the exact syntax, so feel free to suggest something better.) This will give you the capability to attach to existing or new instances of /bin/program_of_interest system-wide. I'm attempting to do this just with utrace. In terms of what I'm working on, I think your requested feature becomes: 1. use utrace to watch the pid of the shell (instead of the entire system) 2. look for the exec of 'pgm' 3. attach the user utrace/uprobes probes to the newly created 'pgm' Is this what you are looking for?
David's work is also closely related to the instruction tracing work (which should have its own separate bugzilla), in that it too exposes utrace-level events. Finally, run-time addition/removal of probes of whatever kind will benefit (require) the work from bug #4935, which should tweak the way the translator emits its *probe setup tables and logic.
(In reply to comment #2) > I've just started working on a related, yet different, feature. It is possible > that the feature this bug talks about could fall out from that work or be a > small addition to it. > > I'm work on providing the ability to do something like: > > probe process("/bin/program_of_interest").create { > # do something here... > } > probe process("/bin/program_of_interest").exit { > # do something here... > } > > (I'm undecided on the exact syntax, so feel free to suggest something better.) I think this will be a really useful feature. It's always been on our user-space-probing wish list. I wonder whether ".create" should be ".exec". In particular, the process.create event in the process.stp tapset refers to fork/create, while process.exec refers to exec. > > This will give you the capability to attach to existing or new instances of > /bin/program_of_interest system-wide. I'm attempting to do this just with utrace. I'll be glad to see this. I could never figure out how to do such a thing with utrace, without a specific ancestor process to start with. > > In terms of what I'm working on, I think your requested feature becomes: > 1. use utrace to watch the pid of the shell (instead of the entire system) > 2. look for the exec of 'pgm' > 3. attach the user utrace/uprobes probes to the newly created 'pgm' > > Is this what you are looking for? Yes.
(In reply to comment #4) > (In reply to comment #2) > > I've just started working on a related, yet different, feature. It is possible > > that the feature this bug talks about could fall out from that work or be a > > small addition to it. > > > > I'm work on providing the ability to do something like: > > > > probe process("/bin/program_of_interest").create { > > # do something here... > > } > > probe process("/bin/program_of_interest").exit { > > # do something here... > > } > > > > (I'm undecided on the exact syntax, so feel free to suggest something better.) > > I think this will be a really useful feature. It's always been on our > user-space-probing wish list. > > I wonder whether ".create" should be ".exec". In particular, the process.create > event in the process.stp tapset refers to fork/create, while process.exec refers > to exec. Obviously "create" isn't the right name, since I really had in mind a probe that gets called for UTRACE_EVENT(CLONE). Perhaps I should just call it "clone". We'd have a separate event called "exec" for UTRACE_EVENT(EXEC). > > > > This will give you the capability to attach to existing or new instances of > > /bin/program_of_interest system-wide. I'm attempting to do this just with utrace. > > I'll be glad to see this. I could never figure out how to do such a thing with > utrace, without a specific ancestor process to start with. You attach your utrace engine to all processes (in theory at least - I haven't got anything working yet). I'm basing my work on the utrace crash-suspend example. Look at the exit_crash_suspend() function to see basically what I'll be doing.
(In reply to comment #5) ... > > > This will give you the capability to attach to existing or new instances of > > > /bin/program_of_interest system-wide. I'm attempting to do this just with > utrace. > > > > I'll be glad to see this. I could never figure out how to do such a thing with > > utrace, without a specific ancestor process to start with. > > You attach your utrace engine to all processes (in theory at least - I haven't > got anything working yet). I'm basing my work on the utrace crash-suspend > example. Look at the exit_crash_suspend() function to see basically what I'll > be doing. Roland's utrace TODO list contains the following: * Global tracing ** Allow a type of engine attached to no particular thread. Perhaps a more efficient "exec watcher" could be built from that. Or maybe this would be an "extension event."
*** This bug has been marked as a duplicate of 6445 ***