[PATCH tracing/kprobes v2 1/5] tracing/kprobes: Rename special variables syntax
Masami Hiramatsu
mhiramat@redhat.com
Mon Oct 5 22:34:00 GMT 2009
Frederic Weisbecker wrote:
> On Mon, Oct 05, 2009 at 05:34:24PM -0400, Masami Hiramatsu wrote:
>> Hmm, one idea hits me, how about this? :)
>> - %register
>> - %%spvars (%%retval, %%arg0)
>
>
> The problem is that such % or %% symbols have a specific
> mean in some other well known areas.
>
> If we borrow the % from the AT&T assembly syntax style
> to use register names, that we can retrieve in gcc inline
> assembly, then one may expect %% to have a meaning inspired
> from the same area. %% has its sense in gcc inline assembly,
> but applied there, it looks confusing.
>
> I mean, I'm trying to think like someone reading a perf probe
> command line without any documentation. The more this person
> can understand this command line without documentation, the better.
> We know that % is used for register names, some people know that %%
> is used for register names too but when we are in gcc inline assembly
> with var to reg resolution and need true registers name.
Hmm, but %%reg syntax is only for the special case of gcc-inline
assembly (e.g. assembler template, see
http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#s3).
So, I guess it will not be so confusing.
> Then if I try to mirror this sense from gcc to perf probe use,
> I feel confused, especially in the case of %%arg1.
>
> In this case, we should rather have %%register and %arg0 :)
>
> Hm, %register is a clear pattern.
>
> Somehow, %retval looks clear too, retval is verbose enough and
> % is still logical as return values are most of the time (always?)
> put in a register.
>
> But %%arg0 looks confusing.
Then, can we use @@ for prefix of special variables?? :-)
I'm so anxious about collision between register name and
those vars.
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com
More information about the Systemtap
mailing list