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

From: Masami Hiramatsu
Date: Mon Oct 05 2009 - 16:16:54 EST


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@xxxxxxxxxx

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