This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Reduction of guru use in systemtap war stories
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: William Cohen <wcohen at redhat dot com>
- Cc: SystemTAP <systemtap at sources dot redhat dot com>
- Date: Mon, 09 Jun 2008 18:24:28 -0400
- Subject: Re: Reduction of guru use in systemtap war stories
- References: <484DA545.7070608@redhat.com>
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