Reduction of guru use in systemtap war stories
William Cohen
wcohen@redhat.com
Tue Jun 10 21:54:00 GMT 2008
Frank Ch. Eigler wrote:
> wcohen wrote:
>
>> I am looking through the war stories and figuring out how to clean
>> things up. [...]
>
> Thanks.
>
>> WSthreadCPUshare uses guru mode to determine the instruction pointer
>> value for the sample and then determine whether this value is in
>> kernel or user-space. For some 32-bit kernels this approach is not
>> correct. A better approach would be make the kernel function
>> user_mode() available in the tapsets. [...]
>
> Indeed, please make it so!
Attached is a simple little patch for the context.stp tapset and documentation
to "make it so." Assuming that it looks okay I will commit it.
>
>> Some of the other war stories (WSPfiles, WSPsig, and WSPlimit) the
>> idiom to map a pid to a task struct point comes up and would be a
>> candidate to add to the tapsets. It looks like some of the other guru
>> functions in those scripts are already available and can be recast as
>> task.stp tapset functions. [...]
>
> See bug #6525 for a probably more robust way. The one used in some of
> that embedded-c code, find_task_by_pid(), is not safe to call from all
> contexts.
Thanks for the pointer to 6525.
>> Several of the war stories (such as WSPfiles) include header files
>> and make use of defines to extract bits/flags out of values. Seems
>> like there should be a cleaner way to make those bit values
>> available to scripts.
>
> One possibility is to lobby the kernel to run gcc with -g3 or somesuch
> to get it to dump macro definitions into the dwarf data; then we could
> pull it out of there with $MACRO. Sounds unlikely.
At the moment asking for -g3 sounds unlikely. The debuginfo is already large.
Adding in all the macros is going to make the debug information even larger.
> Other ideas?
-Will
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stap_user_mode.diff
URL: <http://sourceware.org/pipermail/systemtap/attachments/20080610/cacc8c6f/attachment.ksh>
More information about the Systemtap
mailing list