Skip site navigation (1) Skip section navigation (2)

DTrace for FreeBSD: To-Do-List

We need a BSD version of libelf. Or at least one that can handle host endian != target endian. This affects cross-builds on dissimilar architectures (like i386 host, sun4v target). Works has started on the BSD version of libelf
Get ustack()/stack() actions working
Implement args beyond arg4
Implement lockstat -- including both driver and command
Implement toxic ranges
Implement stop() action
Port MDB DTrace-related dcmds to FreeBSD debugger
Get jstack() action working
Need to add mailbox IPI's to allow a function to be executed on another CPU.
Credentials and privileges need a lot of work.
The ability to trace a process running on a different CPU is an important part of DTrace. Somebody needs to test that.
Solaris has a vmem subsystem which is an integral part of their virtual memory. In DTrace, vmem is only used to create resource IDs. We can use a simple implementation of the functions:

  • vmem_create
  • vmem_destroy
  • vmem_alloc
  • vmem_free

We should just create a bitmap to keep track of which resource numbers we've allocated. Bit zero would be resource ID = 1. Re-allocate the bitmap to a larger one as required.

We don't need to keep the 4 function names above. Doing that would probably confuse people. We should just add compatibility definitions to map whatever function names we choose to the names that the Solaris code wants.

Solaris has a cache as part of vmem too. We need an implementation of the functions:
  • vmem_cache_create
  • vmem_cache_destroy
  • vmem_cache_alloc
  • vmem_cache_free
There are lots of places in the build where the ctfconvert and ctfmerge tools complain about the objects they are processing. Those issues need to be resolved.