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 BirrellReceived on Sun Feb 10 2008 - 21:42:48 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:27 UTC