Re: Reduction of guru use in systemtap war stories

[fche at redhat dot com (Frank Ch. Eigler)]

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!

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

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

Other ideas?


- FChE