New DTrace source snapshot
John Birrell
jb at what-creek.com
Sun Feb 10 22:42:48 UTC 2008
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
More information about the freebsd-current
mailing list