New release of dtrace

I wrote in my previous blog about some issues with the
fasttrap provider and some instruction emulation. After testing
more thoroughly, I found my original cure wasnt strong enough - there
were still some instructions being misinterpreted, leading to app
core failure.

#if linux
        /*********************************************
        /*   Handle:
        /*   41 ff 14 c4 callq *(%r12,%rax,8)
        /*   41 ff 24 f4 jmpq *(%r12,%rsi,8)
        /*********************************************
        sz = base == 5 ? (mod == 1 ? 1 : 4) : 0;
#else
        sz = mod == 1 ? 1 : 4;
#endif

In case anyone is interested, the above works properly for SIB indexed
instructions where there is no offset.

I can now profile crisp and watch it run a few hundred times slower
(if I instrument every instruction in the application). The beauty
of dtrace is that I can cherry pick functions, shared libraries, and
entry/return points of functions, so its possible, for example to put
a trace on a specific function and see if its called or easily
count how many instructions are executed, or even profile
the sequence of instructions (e.g. looking for abnormally long runtimes).

At the moment, theres a slight slowdown due to some debug printk()s
(which you can see in /proc/dtrace/trace); I've removed most of the ones
I was using to do my debugging, but a handle of TODO's remain (need
to fix up the rw_enter/rw_exit functions).

This leaves one thing to fix:

$ dtrace -c cmd ... -n ....

If dtrace is launching the application, it currently doesnt work
properly, because we need to stop the child process as soon as it
launches. Solaris/MacOS have the code in to 'walk' the process to the
starting line, but this doesnt work on Linux, and I need to debug/replace
that code.



Post created by CRiSP v11.0.10a-b6441