DTrace - Subtlety

I have some issue with dtrace on AS4 - Ctrl-c dtrace and it can crash
the kernel. Doesnt happen on my Centos 4.7, so, something to look into
on a rainy day.

Rather than drive myself insane on that issue, I am looking at how
"symbols" work in dtrace. The files installed in /usr/lib/dtrace
provide an "interface" so that D scripts can use symbols and structures
in the kernel.

When I tried a simple probe like this:

$ dtrace -n 'syscall:::{printf("%d", cpu);}"

I started to realise I didnt fully understand what is going on here -
for MacOSX, Solaris, or Linux. Certainly, each platform provides a CTF
file which is a mapping of symbols in the kernel such that dtrace can use
them. But what/where is "cpu"?

Its a strange question, because you get the CPU for free when doing a
dtrace probe. But it isnt a standard variable like "pid", or "execname"
(which work in Linux/dtrace). "cpu" needs to be constructed from a
cpu info structure - this representing the actual cpu we are running
on at the time of the probe firing.

I have the start of the CTF framework in dtrace present, but even though I
have created this code, I am not happy I understand it enough to just
resolve the issue.

For example, every symbol in /proc/kallsyms is available to us in D
scripts, but kallsyms gives us symbols and addresses - not sizes or
typedefs. So, now I need to work out what I am missing. If we can
expose these symbol types into the CTF file, then we can start grabbing
the data, without having to hand craft "constructors" for variables in the
kernel.

Of course, a linux kernel compiled with debug info has all this data available,
and we might use that. (Except I compile my kernels without debug).

I was surprised how "confusing" this area is, until one uses it enough
to really get all the pieces together.

Hopefully will get something going in the next few days/weeks.


Post created by CRiSP v10.0.3b-b5941