From: Frederic Weisbecker <fweisbec@gmail.com>
To: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@elte.hu>,
lkml <linux-kernel@vger.kernel.org>,
systemtap <systemtap@sources.redhat.com>,
DLE <dle-develop@lists.sourceforge.net>,
Thomas Gleixner <tglx@linutronix.de>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Mike Galbraith <efault@gmx.de>, Paul Mackerras <paulus@samba.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Christoph Hellwig <hch@infradead.org>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Jim Keniston <jkenisto@us.ibm.com>,
"Frank Ch. Eigler" <fche@redhat.com>
Subject: Re: [PATCH tracing/kprobes v2 1/5] tracing/kprobes: Rename special variables syntax
Date: Mon, 5 Oct 2009 21:18:31 +0200 [thread overview]
Message-ID: <20091005191829.GA6071@nowhere> (raw)
In-Reply-To: <4AC830F0.2010003@redhat.com>
On Sun, Oct 04, 2009 at 01:21:52AM -0400, Masami Hiramatsu wrote:
> Hmm, # is widely used for comment, including some kernel pseudo
> file interfaces, kprobe_events too. Comments are useful if a
> probe list is restored from a file.
>
Right, let's think about something else.
> For accessing local variables, kprobe-tracer needs to support *at least*
> below variables:
> - Registers
> - Stack address (if a register points stack address, this isn't needed)
Ok.
Well, thinking more about the % sign, we shouldn't worry about
format confusion, since it's a commonly used character for registers,
we can take it for them: %rax, %rbx, etc. (is that what you did
in this patch? I don't remember exactly...)
And for addresses: @addr
> Below special vars are complementary aliases.
> - Function arguments
For the function arguments, I guess we don't need to worry
anymore about r0, r1, etc... but we can deal with the true var
name, without any kind of prefixes.
> - Return value
What about %return ?
As return values are usually stored in a register (at least in Arm
and x86, I don't know about the others), the % prefix fits well for
that.
> - Return address
What about @return :-) ?
That said we shouldn't worry about that in perf, since we can
take snapshots of the backtraces, like in some other perf events.
> and I'd like perf-probe to have a transparent syntax with kprobe-tracer.
That's feasible. But think about the fact that perf probe benefits
from a higher level of code view. Now that we have global and local
variables resolution, we can't anymore expect using r1, r2, rax,
a1, rv, ra without risking to collide with variable names.
But this tracer hasn't been merged yet, so it's still time
to update its interface.
> This means, if we can remove special vars except registers, or rename it
> non-conflictable name with registers, we just need to separate name spaces
> of
> - Regsiters
> - Local variables
Yeah.
> Here, local variables will support fields of data structs, and it will
> use '->' expression. Since '>' means redirection in bash, local variables
> need to be *escaped* in this case. Thus, I think we can use '$' prefix
> for it. (I'm OK, because this is similar syntax to systemtap:-).
>
> So, if you don't like %regs, $svars and locals, we can use regs and $locals :-)
'>' means redirection, but at least inside quotes it's not interpreted.
I'm fine with %regs actually. But I really don't like the "$" because
I really worry about shell substitutions.
Most people delimit their strings with double quotes.
What if we take the following:
[Ftrace and perf probe side]
%reg = registers, we can also play with deref and offsets like (%esp), 8(%esp), etc.
%return = return value
@return = return addr
arg(n) = arg number, where n is the number
[Perf probe only]
var = variable name, global or local, we can deal with shadow issues later
through variable scope: func_name:var, filename:var, whatever for now
it's not a problem. Local also includes argument names.
Hmm?
next prev parent reply other threads:[~2009-10-05 19:19 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-02 21:48 [PATCH tracing/kprobes v2 0/5] tracing/kprobes, perf: perf probe support take 2 Masami Hiramatsu
2009-10-02 21:48 ` [PATCH tracing/kprobes v2 1/5] tracing/kprobes: Rename special variables syntax Masami Hiramatsu
2009-10-03 1:54 ` Frederic Weisbecker
2009-10-04 5:21 ` Masami Hiramatsu
2009-10-05 16:59 ` Masami Hiramatsu
2009-10-05 19:26 ` Frederic Weisbecker
2009-10-05 21:05 ` Masami Hiramatsu
2009-10-05 21:11 ` Frederic Weisbecker
2009-10-06 0:12 ` Steven Rostedt
2009-10-06 14:23 ` Masami Hiramatsu
2009-10-06 22:47 ` Frederic Weisbecker
2009-10-07 1:13 ` Masami Hiramatsu
2009-10-07 16:28 ` Frederic Weisbecker
2009-10-07 0:15 ` Steven Rostedt
2009-10-07 2:57 ` Masami Hiramatsu
2009-10-06 22:42 ` Frederic Weisbecker
2009-10-05 19:18 ` Frederic Weisbecker [this message]
2009-10-05 19:38 ` Frederic Weisbecker
2009-10-05 20:18 ` Masami Hiramatsu
2009-10-05 20:58 ` Frederic Weisbecker
2009-10-05 21:11 ` Masami Hiramatsu
2009-10-05 21:21 ` Frederic Weisbecker
2009-10-05 21:34 ` Masami Hiramatsu
2009-10-05 21:55 ` Frederic Weisbecker
2009-10-05 22:09 ` Frederic Weisbecker
2009-10-05 22:38 ` Masami Hiramatsu
2009-10-05 22:42 ` Masami Hiramatsu
2009-10-02 21:48 ` [PATCH tracing/kprobes v2 2/5] tracing/kprobes: Avoid field name confliction Masami Hiramatsu
2009-10-06 0:16 ` Steven Rostedt
2009-10-06 1:07 ` Masami Hiramatsu
2009-10-02 21:48 ` [PATCH tracing/kprobes v2 3/5] tracing/kprobes: Rename fixed field name Masami Hiramatsu
2009-10-02 21:49 ` [PATCH tracing/kprobes v2 4/5] perf: Add perf probe subcommand for kprobe-event setup helper Masami Hiramatsu
2009-10-06 0:29 ` Steven Rostedt
2009-10-06 0:57 ` Masami Hiramatsu
2009-10-06 1:20 ` Steven Rostedt
2009-10-06 1:43 ` Arnaldo Carvalho de Melo
2009-10-06 9:03 ` Peter Zijlstra
2009-10-07 3:22 ` Masami Hiramatsu
2009-10-02 21:49 ` [PATCH tracing/kprobes v2 5/5] perf: kprobe command supports without libdwarf Masami Hiramatsu
2009-10-03 1:25 ` [PATCH tracing/kprobes v2 0/5] tracing/kprobes, perf: perf probe support take 2 Frederic Weisbecker
2009-10-05 14:54 ` Frank Ch. Eigler
2009-10-05 15:10 ` Masami Hiramatsu
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=20091005191829.GA6071@nowhere \
--to=fweisbec@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=ananth@in.ibm.com \
--cc=dle-develop@lists.sourceforge.net \
--cc=efault@gmx.de \
--cc=fche@redhat.com \
--cc=hch@infradead.org \
--cc=jkenisto@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=rostedt@goodmis.org \
--cc=systemtap@sources.redhat.com \
--cc=tglx@linutronix.de \
/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 NNTP newsgroup(s).