CRiSP Newsletter
Testimonials
| 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 Read more http://crtags.blogspot.com/2011/01/dtrace-oops.html |




