New DTrace source snapshot

John Birrell jb at
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.


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

More information about the freebsd-current mailing list