Latest DTrace news

I havent much worked on DTrace recently - having been looking at
some side projects (adding multiple cursor support to CRiSP, my
rss.pl enhancements, and various bugs/enhancements in CRiSP).

Of course, when I stop looking at dtrace, after a while, a trickle
of things come in. I thought I would summarise some of my "TODO" items.

First, a user reported an issue on a 3.2 kernel. Seems like a Xen
hosted kernel is very unreliable. Although he reported an issue with
an fbt::: torture test, I could reproduce with a task switch
function - even after a few probes, suggesting the basic handling of an
IRET instruction may be having problems on Xen. (Xen does paravirtualisation
which is another way of saying, all the work is on the user and
not itself, to virtualise. I really do not like Xen - its a work
generation scheme!)

Next was an issue with the PID provider. I did start working on this
and found some missing functionality in libproc/libdtrace. I started
working on this, but its not ready for consumption. I have included
the partial work in the next release. At issue is running a process
and intercepting the shlib events so that dtrace can look at the
shlib and add probes.

Next up is the 3.12 kernel. I usually leave it a while before touching
new kernels - Ubuntu 14.04 is due in a few weeks and I can kill two
birds with one stone by waiting for that to come out.

Another annoyance is the libdwarf vs libdw confusion which prevents
ctfconvert from being built. This is mostly irrelevent unless people
want to use kernel struct's in their probes. I need to discard
both libraries and use readelf and parse the output from it - its
the only portable way to do what is necessary vs the confusion
inherent in both dwarf libraries.

So, its unlikely I will release a new dtrace release for a few more
weeks, unless I magically fix one or more of the issues above.


Post created by CRiSP v11.0.26a-b6707