From: Masami Hiramatsu <mhiramat@redhat.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
systemtap-ml <systemtap@sources.redhat.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH -tip 3/5 V2] tracing: kprobe-tracer plugin supports arguments
Date: Sat, 21 Mar 2009 16:57:24 -0400 [thread overview]
Message-ID: <49C554B4.7020303@redhat.com> (raw)
In-Reply-To: <20090321025551.GG6044@nowhere>
Frederic Weisbecker wrote:
>> +
>> +#if defined(__i386__)
>> +#define REGPARMS 3
>> +static unsigned long fetch_argument(struct pt_regs *regs, void *data)
>> +{
>> + unsigned long n = (unsigned long)data;
>> + if (n > REGPARMS) {
>> + /*
>> + * The typical case: arg n is on the stack.
>> + * stack[0] = return address
>> + */
>> + return fetch_stack(regs, (void *)(n - REGPARMS));
>
>
> I wonder if it wouldn't be better to make this tracer depend on
> CONFIG_FRAME_POINTER. So that wherever we probe inside a function,
> the argument asked keeps being reliable. esp will move, ebp will not until
> we quit the frame.
Hm, AFAIK, CONFIG_FRAME_POINTER is for unwinding stacks, but I doubt
it is useful for getting function arguments, because first nth parameters
are passed by registers which will easily be broken and compilers may
change register assignment in the function body.
I guess that most of debugging users will disassemble kernel binary
when setting a probe (I recommend it, at least with this version.)
So they can find what they want by analyzing assemble code.
Anyway, I think it is possible to get a stack entry referred from
ebp(stack frame register) by implementing below item.
> - Support indirect memory fetch from registers etc.
This will allow us to access memory indirectly like as;
p sys_open+10 r5[8]
This will mean "record *(ulong)(pt_regs->bp+8) at sys_open+10"
(syntax is not fixed yet.)
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com
prev parent reply other threads:[~2009-03-21 20:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-21 1:33 [RFC][PATCH -tip 3/5 V2] tracing: kprobe-tracer plugin supports arguments Masami Hiramatsu
2009-03-21 2:55 ` Frederic Weisbecker
2009-03-21 20:57 ` Masami Hiramatsu [this message]
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=49C554B4.7020303@redhat.com \
--to=mhiramat@redhat.com \
--cc=ananth@in.ibm.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--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