From: William Cohen <wcohen@redhat.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: SystemTAP <systemtap@sources.redhat.com>
Subject: Re: Reduction of guru use in systemtap war stories
Date: Tue, 10 Jun 2008 21:54:00 -0000 [thread overview]
Message-ID: <484ED54F.1010903@redhat.com> (raw)
In-Reply-To: <y0mr6b6nt5v.fsf@ton.toronto.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]
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
[-- Attachment #2: stap_user_mode.diff --]
[-- Type: text/plain, Size: 911 bytes --]
diff --git a/stapfuncs.5.in b/stapfuncs.5.in
index 6d4546a..d8a1a55 100644
--- a/stapfuncs.5.in
+++ b/stapfuncs.5.in
@@ -252,6 +252,9 @@ Return the probe point's module name, if known.
target:long ()
Return the pid of the target process.
.TP
+user_mode:long ()
+Return 1 if the probe point occurred in user-mode.
+.TP
is_return:long ()
Return 1 if the probe point is a return probe. Deprecated.
diff --git a/tapset/context.stp b/tapset/context.stp
index 45e3be3..d2195f8 100644
--- a/tapset/context.stp
+++ b/tapset/context.stp
@@ -140,6 +140,11 @@ function registers_valid:long () %{ /* pure */
THIS->__retvalue = (CONTEXT->regs != NULL);
%}
+function user_mode:long () %{ /* pure */ /* currently a user-mode address? */
+ if (CONTEXT->regs)
+ THIS->__retvalue = (uint64_t) user_mode (CONTEXT->regs);
+%}
+
function is_return:long () %{ /* pure */
if (CONTEXT->pi)
THIS->__retvalue = 1;
next prev parent reply other threads:[~2008-06-10 19:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-09 22:32 William Cohen
2008-06-10 8:10 ` Frank Ch. Eigler
2008-06-10 21:54 ` William Cohen [this message]
2008-06-11 16:47 ` William Cohen
2008-06-27 20:59 ` Roland McGrath
2008-06-30 19:49 ` William Cohen
2008-06-30 20:49 ` Roland McGrath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=484ED54F.1010903@redhat.com \
--to=wcohen@redhat.com \
--cc=fche@redhat.com \
--cc=systemtap@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).