On 2/11/08, John Birrell <firstname.lastname@example.org> 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.
> Known problems:
> - This is a snapshot of current which contains lock order
> reversal warnings. These are not related to the DTrace-specific
> - 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.
> - 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);
> 'memref' is an an array of 2 uintptr_t entries -- address and
> 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
> 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