Re: New kernel marker wiki page

["K.Prasad" <prasad@linux.vnet.ibm.com>]

Hi David and all,
		Thanks for posting the wiki.

I thought I would bring the issue of handling structure pointers in SystemTap
script for the members to deliberate upon.

Quoting the wiki here to bring the context:

"How are marker arguments handled that are structure pointers?

Not well. Because systemtap has no DWARF information for marker arguments, it
really doesn't know what type they are. In a DWARF-based probe, you could write
something like this:

probe kernel.function("kfunc") { printf("inode number: %d\n", i->i_ino) }

However, if you try something similar with a marker-based probe, you'll get an
error because systemtap doesn't know that:
* $arg1 is a pointer
* the type of what $arg1 points to"

Solutions to this problem, as detailed in the wiki, and their shortcomings as I
see are:

* Solution proposed - "Use Guru mode (-g option) to embed C code that type-casts
the datatype to the requisite format" - It would be less desirable to clutter
the scripts with embedded C code, and would potentially take away the
'abstraction' and security that these SystemTap scripts are expected to provide.

* Solution proposed - "go ahead and put the interesting structure fields in the
marker itself" - From the previous discussions related to marker patches
(submitted for RCU debugging infrastructure), it was apparent that the community
desired the least amount of instrumentation code in the kernel. This would be
more pronounced when markers are proposed in critical code regions which would
have in the performance of the system. In such cases we may have to export the
parent data structure (which will enable us to extract all the data-members of
the structure of interest, in the marker handler/SystemTap script). Say, if we
have a structure struct X { a, b, c,.....z} and if we are interested in only a
few members (although not all), it would still be worthwhile to embed the
instance of 'struct X' in the trace_mark() - to optimise the marker for a
not-taken case.

* The other method would be to make a similar declaration of the data structure
and use them. But again, this comes with costs such as - bloating of SystemTap
scripts, added complexity and maintenance overhead (keep the data type of the
parameters in the script in sync with the kernel).

Given these usability issues for SystemTap over markers in the absence of DWARF
information, would it still be a good idea to exclude DWARF information or are
there other plans to mitigate them?

Thanks,
K.Prasad

On Mon, 14 Jan 2008 21:38:15 +0530, David Smith <dsmith@redhat.com> wrote:

> I've gotten requests for more kernel marker information, so I decided to
> summarize what I know on a new wiki page:
>
> <http://sourceware.org/systemtap/wiki/UsingMarkers>
>
> (It was a useful exercise, since I discovered bug 5608 while writing the
> page.)
>
> If you see any additional areas (or have additional questions) that need
> covering send me an email or add the info yourself.
>
> I hope this helps.
>