From: Masami Hiramatsu <mhiramat@redhat.com>
To: Frederic Weisbecker <fweisbec@gmail.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, 05 Oct 2009 12:59:01 -0400 [thread overview]
Message-ID: <4ACA25D5.10703@redhat.com> (raw)
In-Reply-To: <4AC830F0.2010003@redhat.com>
Masami Hiramatsu wrote:
> Frederic Weisbecker wrote:
>> On Fri, Oct 02, 2009 at 05:48:42PM -0400, Masami Hiramatsu wrote:
>>> FETCHARGS : Arguments. Each probe can have up to 128 args.
>>> %REG : Fetch register REG
>>> - sN : Fetch Nth entry of stack (N>= 0)
>>> - sa : Fetch stack address.
>>> @ADDR : Fetch memory at ADDR (ADDR should be in kernel)
>>> @SYM[+|-offs] : Fetch memory at SYM +|- offs (SYM should be a data symbol)
>>> - aN : Fetch function argument. (N>= 0)(*)
>>> - rv : Fetch return value.(**)
>>> - ra : Fetch return address.(**)
>>> + $sN : Fetch Nth entry of stack (N>= 0)
>>> + $sa : Fetch stack address.
>>> + $aN : Fetch function argument. (N>= 0)(*)
>>> + $rv : Fetch return value.(**)
>>> + $ra : Fetch return address.(**)
>>
>>
>>
>> I feel uncomfortable with that, because of bash scripts that
>> may use it and always need to escape it with antislashes or
>> use single quotes for it to not be replaced by a random variable
>> value. If one uses double quotes without antislashes to protect
>> the command line, the result is unpredictable, depending of
>> the current set of variables...
>>
>> May be we can use # instead of $ ? That's a kind of pity because
>> $ suggested a variable whereas # suggests a constant, we are then
>> losing this self-explainable characteristic for kprobes
>> "specific variable fetchs". But that will work without ambiguity.
>
> 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.
>
> 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)
>
> Below special vars are complementary aliases.
> - Function arguments
> - Return value
> - Return address
>
> and I'd like perf-probe to have a transparent syntax with kprobe-tracer.
>
> 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
>
> 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 :-)
As far as I can see in arch/*/include/asm/ptrace.h, all registers start with
alphabets :-). So, I'd like to suggest renaming sp-vars to '_sp-vars'.
Then, we will have;
- $local-vars
- @global-symbol
- regs
- _sp-vars
- +|-Offs(ARG)
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com
next prev parent reply other threads:[~2009-10-05 16:56 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 [this message]
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
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=4ACA25D5.10703@redhat.com \
--to=mhiramat@redhat.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=fweisbec@gmail.com \
--cc=hch@infradead.org \
--cc=jkenisto@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--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).