Re: DTrace SDT Provider not working?

Hi John,

thanks for your answer!

On Sun, 11 Jun 2006 18:38:09 +0000
John Birrell <jb_at_what-creek.com> wrote:

> 
> [ I forgot to copy current_at_ ]
> 
> On Sun, Jun 11, 2006 at 02:53:51PM +0200, Marius Nuennerich wrote:
> >
> > I tried to add the SDT Hooks for callout(9), see attached patch.
> > > # dtrace -l -f callout
> > >    ID   PROVIDER            MODULE                          FUNCTION NAME
> > >     6        sdt            kernel                           callout entry
> > >     7        sdt            kernel                           callout return
> >
> > however, a simple
> >
> > > # dtrace -n 'sdt:kernel:callout:entry{printf("1");}'
> >
> > prints that a probe is matched but nothing else, same for
> > sdt:kernel:linker_load_module:entry and kldload'ing a module.
> >
> > I use the snapshot code you provided.
> >
> > Any idea where to look next?
> 
> Are you sure that the function is actually being called?

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?

> Using fbt you will be able to see what functions are being called
> more easily. This might explain what is happening with the sdt code
> you've added (which looks like it should work).

Ok. Thanks for the Hint. It seems like the softclock function is not
known to fbt by default right now.

I wonder why sdt:kernel:linker_load_module:entry isn't fired when
kldload'ing, does it work on your machine(s)?

regards
Marius

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?

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.