So, I’ve been spending some time looking at Dtrace today. At first, I created a proof of concept on OS X, and then went on to try it in production on FreeBSD.

No such luck. After several hours of trying to figure out what the heck was going wrong, I tried the following experiment, on OS X.

% uname -a
Darwin foo 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep  1 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64
% cat hello.c
#include <stdio.h>

int main(int argc, char *argv[]) {
printf( "Hello\n" );
return 0;
}
% dtrace -n 'pid$target::main:entry{printf("%#p\n",uregs[R_RBP]);}' -c ./hello
dtrace: description 'pid$target::main:entry' matched 1 probe
Hello
dtrace: pid 9224 has exited
CPU     ID                    FUNCTION:NAME
0    67470                       main:entry 0x7fff583c1c20

And then again on FreeBSD.

% uname -a
FreeBSD bar 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 15:26:37 UTC 2015     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
% cat hello.c
#include <stdio.h>

int main(int argc, char *argv[]) {
    printf( "Hello\n" );
    return 0;
}
% dtrace -n 'pid$target::main:entry{printf("%#p\n",uregs[R_RBP]);}' -c ./hello
dtrace: description 'pid$target::main:entry' matched 1 probe
Hello
dtrace: pid 84313 has exited
CPU     ID                    FUNCTION:NAME
  2  54008                       main:entry 0

As you can see, the printed value of the %rbp register is zero on FreeBSD. In my experiments, trying to read that register always yields zero. Similarly, I do not trust it for other registers.

This seems to be a bug in FreeBSD’s Dtrace. At the time of this writing, I have not tried it on recent Illumos.