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 --- fastest mac firefox! http://wagerlabs.com
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, JoelThat was me: you can use -x evaltime=mode exec preinit postinit main preinit is the default. exec stops in the linker on return from exec(2) into the new process -Mike -- Mike Shapiro, Sun Microsystems Open Storage / Fishworks. blogs.sun.com/mws/
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 > mainThis 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
James, On Aug 31, 2009, at 9:28 PM, James McIlree wrote:> 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).I switched to Snow Leopard to get it to work right. It seems to work.> 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.So stop is not necessary then? This is how I do it at the moment... proc:::exec-success /execname == progname/ { stop(); system("dtrace %s -p %d %s\n", opts, pid, scripts); exit(0); } then, in another script BEGIN { system("kill -CONT %d &\n", $target); }> syscall::getpid:entry > / should_make_process_wait[pid] == 1 / > { > should_make_process_wait[pid] = 0; > printf("Stopping %s (%d)\n", execname, pid); > stop(); > }Is this how you suggest I should be doing it?> The final evilness is that stop() is implemented via sending a > SIGSTOP, which is user visible.I certainly do notice this. Thanks, Joel --- fastest mac firefox! http://wagerlabs.com