Re: New DTrace source snapshot

On 2/11/08, John Birrell <jb_at_what-creek.com> wrote:
> This one fixes problems with the previous one:
>
> - buildkernel would fail because NO_CTF=1 was not set when
>   building the lone kernel build tool.
> - A number of things were missing from the dtrace kernel
>   module on i386.
> - Missing syscall names in the kernel without witness have
>   been resolved so this snapshot should build with and without
>   witness, invariants, smp etc.
>
> <http://people.freebsd.org/~jb/dtrace/dtrace-20080211.tar.bz>
>
> Known problems:
> - This is a snapshot of current which contains lock order
>   reversal warnings. These are not related to the DTrace-specific
>   code.
> - ustack() as reported by Drew hasn't been ported yet, so don't
>   expect it to do anything.
> - On i386 mp_maxid in the kernel doesn't behave the same way that
>   it does on amd64. Work-around code exists for this, but it is
>   less than optimal.
> - A few of the tests that pass on amd64 don't work on i386. The
>   causes are under investigation. The worst one is the tailcall
>   test which causes the machine to reboot. Ugh.
>
> Note:
> - This snapshot should build cleanly on either a CURRENT or a
>   RELENG_7 system. If not, please tell me. RELENG_6 users should
>   upgrade to RELENG_7 first or contact me. The tool bootstrap
>   will fail to build when hosted on RELENG_6.
> - It should be ABI compatible with CURRENT and RELENG_7. If
>   not, please tell me.
> - This snapshot extends the basic OpenSolaris DTrace functionality
>   to support:
>
>   printm(const size_t bufrsize, uintptr_t *memref);
>
>   where:
>
>   'memref' is an an array of 2 uintptr_t entries -- address and
>   size.
>
>   Usage example:
>
>   printm(500, memref(mypointer, mysize));
>
>   reserves buffer space of 500 bytes to trace memory at address
>   'mypointer' with size 'mysize'. Both 'mypointer' and 'mysize'
>   can be variables in the D script.
>
>   By contrast, OpenSolaris only supports tracemem(ptr, const size)
>   where 'size' is fixed at compile time. This is not terribly
>   useful when tracing protocols or variable read sizes where the
>   data indicates how long the memory object is.
>
> Target audience:
>
>   I'd like to get more people involved with running this code.
>   If you just like to follow FreeBSD current and don't even try
>   to contribute stuff back... this snapshot is something you
>   could try. I need some feeback from people who just use
>   FreeBSD-CURRENT.
>
> --
> John Birrell

Dtrace on FreeBSD is really amazing! Thanks!

I have one question though, is the anonymous tracing during boot
supported on fbsd?
I have created the required /boot/dtrace.dof file, and set
dtrace_boot="YES" in loader.conf,
but after reboot dtrace -ae doesn not produce anything

  --Niki