new dtrace release - pid provider

Started trying to figure out why this doesnt work.
After a lot of user land deep diving, I found a real
stupidity - I forget/didnt realise to implement
the ioctl() interface to /dev/fasttrap.

That is where the PID provider interface comes into
life !

Theres a few other bug fixes in the area of userland
dtrace getting to the PID provider, but it still doesnt
work, and at least now, I can start to debug the missing
piece(s).

If you look at /proc/dtrace/trace, after invoking the
PID provider, you will see something like:

#0 4753:ESRCH dtrace_ioctl pvp=00000000
#0 4753:fasttrap_ioctl:2238: here
#0 4753:fasttrap_ioctl:2238: here
#0 4753:fasttrap_ioctl:2238: here
#0 4753:fasttrap_ioctl:2250: here
#0 4753:fasttrap_ioctl:2275: here
#0 4753:here in fasttrap_add_probe
#0 4753:fasttrap_provider_lookup: here
#0 4753:prfind 0
#0 4753:prfind:find_get_pid couldnt locate pid 0

This means we got as far as the driver, but theres a couple of blips.
One is that libdtrace is passing down PID#0 no matter what PID you
specify (something in the translation from Solaris /proc handling
to Linux, where I have forgotten to set the PID), and the
other is "prfind()".

"prfind()" is the Solaris kernel function to lookup a process
by PID. That needs to be mapped to the Linux interface, but, the
code calling this relies on the Solaris "struct proc" layout and fields,
so that code has to be walked through to do the right thing.

Once this is resolved (and theres some complexity in scheduler and
process locking, since Linux/Dtrace doesnt modify kernel code), then
hopefully the PID provider can spring into action.

This is actually pretty good progress - having spent a long time
trying to get ELF handling working, I hadnt realised that some
code from near day-0, was a "TODO" item.


Post created by CRiSP v11.0.10a-b6436