Date: Sun, 11 Jun 2006 20:34:16 +0000 From: John Birrell <jb@what-creek.com> To: Marius Nuennerich <marius.nuennerich@gmx.net> Cc: current@freebsd.org Subject: Re: DTrace SDT Provider not working? Message-ID: <20060611203416.GA60954@what-creek.com> In-Reply-To: <20060611221114.2caacdcc@sol.hackerzberg.local> References: <20060611145351.221ec001@sol.hackerzberg.local> <20060611183809.GA60353@what-creek.com> <20060611221114.2caacdcc@sol.hackerzberg.local>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jun 11, 2006 at 10:11:14PM +0200, Marius Nuennerich wrote: > I added a printf after the first SDT_PROBE I added to kern_timeout.c. > That prints very often on the console even after boot. > > > The version of code you have has the fbt provider restricted to just a > > few probes. You could try changing the filter in that to allow it > > to look at more functions. Be warned though that there are some that > > aren't safe to instrument. I'm still tracking those down, so enabling > > all probes with fbt::: is very unwise if you remove the filter I have > > in there. > > Ok, where can I tune the filter? Look at the file sys/cddl/dev/fbt/fbt.c and the function fbt_provide_module_function. You should be able to understand the code. 8-) > Ok. Thanks for the Hint. It seems like the softclock function is not > known to fbt by default right now. That's because I left a version of fbt.c with just about everything filtered out. I'm in the process of trying to track down which functions are being called illegally during the execution of a probe. At the moment I suspect that it is witness in something that needs to have a dtrace specific version. > I wonder why sdt:kernel:linker_load_module:entry isn't fired when > kldload'ing, does it work on your machine(s)? It does for me. Remember that at this stages it's only single processor i386 systems that are supported. > P.S. > sdt:kernel:callout:entry: > 0xeb 0x00 0xa1 0xbc 0x75 0x9c 0xc0 0x8b 0x15 0xc0 0x75 0x9c 0xc0 0x09 > 0xc2 0x74 0x13 0x6a 0x00 0x6a 0x00 0x6a 0x00 0x6a 0x00 0x53 0x50 0xff > 0x15 0x50 0x5d 0x9c 0xc0 0x83 0xc4 0x18 > > Is printed on boot. Is it normal that it is this many Bytes? I thought > it would just be the jmp (0xeb) directly followed by a one byte > offset? The whole sdt implementation needs to change to do it like Sun does in Solaris. The current implementation was developed before I had added the support for invalid opcode exceptions. > P.P.S. Why do you use a near jmp instead of NOPs? Just curious. > Is there any documentation for implementation details of DTrace, > haven't found much so far. The only documentation for the implementation of DTrace is the code itself. 8-) -- John Birrell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060611203416.GA60954>