Re: [PATCH tracing/kprobes v2 1/5] tracing/kprobes: Rename specialvariables syntax

[Frederic Weisbecker]

On Mon, Oct 05, 2009 at 09:18:31PM +0200, Frederic Weisbecker wrote:
> 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.


Sorry, as you pointed out, it's better to keep the same syntax for
both perf probe and ftrace, but having perf probe able to support
variable name.

Hence the following that don't collide: varname, arg(n)


> 
> > - 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.
> 



But we need to worry about it because we want to share the ftrace syntax.
So yeah, why not @return ?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/