Hi,
I am trying to trace some functions that are executed at detach time, and it
seems that just
having dtrace around to instrument the module is causing a short circuit,
whereas modunload will
return (device busy). I understand that this makes sense, but how can I get
around this if I
want to trace stuff at detach time?
Thanks,
--S
On Mon, Aug 22, 2005 at 04:12:39PM -0700, Seth Goldberg wrote:> Hi, > > I am trying to trace some functions that are executed at detach time, > and it seems that just > having dtrace around to instrument the module is causing a short circuit, > whereas modunload will > return (device busy). I understand that this makes sense, but how can I > get around this if I > want to trace stuff at detach time?Your best bet is to use something like kmdb(1) to do the tracing; dtrace prevents the module from being unloaded if any of the module''s probes are active. Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
Hi, }Your best bet is to use something like kmdb(1) to do the tracing; dtrace }prevents the module from being unloaded if any of the module''s probes are }active. I know -- it seems to be the only functionality missing. What was the motivation behind refusing to unload a module when probes are enabled? Was it just to keep the symbols/CTF around so that when the tracing data makes it out to userland, dtrace(1M) will be able to correlate the addresses? If that''s the only reason, why not let the module unload operations (such as detach, etc) occur, but retain the module in memory? --S
On Tue, Aug 23, 2005 at 11:01:49AM -0700, Seth Goldberg wrote:> Hi, > > }Your best bet is to use something like kmdb(1) to do the tracing; dtrace > }prevents the module from being unloaded if any of the module''s probes are > }active. > > I know -- it seems to be the only functionality missing. What was the > motivation behind refusing to unload a module when probes are enabled? > Was it just to keep the symbols/CTF around so that when the tracing data > makes it out to userland, dtrace(1M) will be able to correlate the > addresses? If that''s the only reason, why not let the module unload > operations (such as detach, etc) occur, but retain the module in memory?Presumably, it was so that when the probes are disabled, fbt/sdt doesn''t try to muck with the text after it has been freed. The test that causes the unload to fail is in moduninstall(): http://cvs.opensolaris.org/source/xref/usr/src/uts/common/os/modctl.c#moduninstall 2853 if (mp->mod_prim || mp->mod_ref || mp->mod_nenabled != 0) 2854 return (EBUSY); mod_nenabled is the number of enabled sdt and fbt probes. I''ve filed an RFE: 6314764 fbt/sdt should be able to trace unloading operations Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development