Re: New kernel marker wiki page

[David Smith <dsmith at redhat dot com>]

K.Prasad wrote:
> Hi David and all,
> 		Thanks for posting the wiki.

Thanks for reviewing it.

> 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.

...

> 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.

Note that in the case of markers, we have to avoid looking at things in
a too systemtap-specific way and remember there are other marker users.
 The biggest one, of course, is ltt.  The only solution that ltt has
(that I know of) is the second one listed above - embedding all the
interesting structure fields in the marker itself.  Because of this, I
expect most markers will take that approach - especially since ltt is
also writing the marker patches that are trying to make it to the
upstream kernel.

As to your suggestion of somehow using DWARF information to help us out
with markers, I thought we were trying to figure out ways of moving away
from such a great dependence on DWARF information, not trying to add
more dependence.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)