Dtrace : oops

Just an update - I noticed some minor annoyances in dtrace, which I
want to fix, so I can use it in anger. Here they are:

Cant trace syscalls for a 32-bit app on a 64-bit kernel. Duh! Yes,
but I never finished that work so I forgot!

Access to "cpu" for printing doesnt work unless the /usr/lib/dtrace
files are installed. Sometimes I run from a build dir, and thats annoying
so I will see if I can modify dtrace to look where the binary is running
from rather than just the lib. (You can override the include dir on the
command line, but its too much work to read the help that dtrace provides
or that I augmented :-) Double-duh!)

I notice some fbt "entry" points dont have corresponding "return"
exits, which is a nuisance. Probably the disassembler is missing some
magic in the instruction sequences, so will look to tidy that up.

Still not happy with timestamps in dtrace - they appear to work,
yet everytime I try to measure entry-to-exit times, the values look "wrong",
e.g. it almost looks like the timestamp (hrtime) code is freezing the
value for all matched probes rather than the wall clock time. Not sure
if its me being a dtrace-noobie, or some sillyness in the code.
(Theres also a bug in reading 64-bit timestamps where the low order 32-bits
can wrap and lead to "negative" time occasionally; either that, or a problem
when context switches cpus).

Also, could do better at providing context-switch provider probes, as
thats something always useful.

And lastly, really need to provide a mutex provider, since the linux
kernel inlines the assembler for locks and semaphores, and make it impossible
to count or monitor these probes.

Thats enough to keep me busy for a few days, as my crisp fixes slip behind.
(Getting line wrapping to work properly without display surprises is time
consuming, even trying to remember how the code was supposed to work).

Post created by CRiSP v10.0.3a-b5931