On Aug 28, 2009, at 5:33 PM, Mike Shapiro wrote:
On Sat, Aug 29, 2009 at 01:23:34AM +0100, Joel Reymont wrote:
Adam,
I heard from Brendan Gregg that you implemented some tricky code to
make sure dtrace got in very early in the process with -c ...
Can those tricks be implemented to catch a process very early with
exec-success (or similar) and trace it's dynamic linking, for
example?
As it stands, exec-success seems to get in so late that I miss main()
sometimes.
Thanks, Joel
That was me: you can use -x evaltime=mode
exec
preinit
postinit
main
This will not work correctly in Leopard (10.5), I made some changes
in SnowLeopard (10.6) so
that -x evaltime=exec does do the right thing (tm).
However, this code is still fairly messy on OS X, with some evil bugs.
Most importantly, proc::exec-success is not always firing in the
correct context. My memory
is hazy, but I believe we got it wrong in vfork... The upshot is that
you cannot always safely stop() in
proc::exec-success.
We did a hideous hack workaround where we monitored exec-success to
see new processes launching,
and to decide if we wanted to stop() them. Then we set a probe on a
syscall invoked very early in process
creation and did the stop there:
syscall::getpid:entry
/ should_make_process_wait[pid] == 1 /
{
should_make_process_wait[pid] = 0;
printf("Stopping %s (%d)\n", execname, pid);
stop();
}
The final evilness is that stop() is implemented via sending a
SIGSTOP, which is user visible.
Some shells will notice that children have been STOP'd, and behave
differently (going back to the prompt,
instead of waiting).
I do hope to fix all this, as I said, its pretty squicky :-(.
James M
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
