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

[Masami Hiramatsu <mhiramat@redhat.com>]

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

Yeah, that's what it does currently.

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

This depends on ABI, function argument from ABI doesn't need
debuginfo, but it will be unstable on some arch, e.g. x86-32
with/without asmlinkage.

Thus, I think that we can just describe where function arguments
will be(e.g. arg0 is ax) as a note for each architecture
in Documents/trace/kprobetrace.txt.

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

Sure, that's what I

>> - Return address
>
>
> What about @return :-) ?

Hmm, it might conflict with global symbol... Maybe, we can remove this
because retprobe already shows return address in the head of entry.

(BTW, ideally, I think 'IP' should be the return address in kretprobe.
  But current implementation isn't.)

> That said we shouldn't worry about that in perf, since we can
> take snapshots of the backtraces, like in some other perf events.

Agreed.

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

Sure.

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

Ah, indeed.

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

Sure, especially C programmers :-)

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

Hmm, on x86-32, sp at intr context is not pointing the top of stack. actually &sp is
the real address of the stack :(
Perhaps, on x86-32, we can translate %sp to stack address in kprobe-tracer.

 > %return = return value

or %retval? :)

> @return = return addr

I'd like to remove it, because it's already shown.

> arg(n) = arg number, where n is the number

How about %N? or just adds a note in documents.


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

That's fine to me. :-)

Thank you!

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com