stap += dwarfless probing (phase 2)

stap += dwarfless probing (phase 2)

[Jim Keniston]

This week I've updated the public "dwarfless" branch with support for
the "Phase 2" features on i386 and x86_64:

a. Access to a probed function's arguments by number (since without
dwarf you don't know their names).  This is implemented as a set of
tapset functions with names of the form TYPE_arg(n), where TYPE is
one of [u]int, [u]long, [u]longlong, pointer, s32, u32, s64, or u64;
and n=1 for the first arg, 2 for the second, etc.

b. Access to the registers saved in pt_regs, by name --
e.g., register("eax") to get regs->eax as a signed number, and
u_register("eax") to get it as an unsigned number (i.e., zero-extended
to 64 bits).

All this is documented in the NUMBERED FUNCTION ARGUMENTS and CPU
REGISTERS sections of stapfuncs.5.in.

The only "test" I've checked in so far is tapset/nd_syscalls.stp.
This is a copy of syscalls.stp with several aliases modified to use
numbered arguments instead of named arguments.  (Look for "_arg".)
The nd_syscall.* aliases produce the same results as the syscall.*
aliases, and the eventual intent is for most or all of them to work
even in the absence of dwarf.

According to my ad hoc testing, the *_arg(n) and [u_]register(name)
functions can also be used when probing user apps (i.e., using
Frank's old process(PID).statement(VADDR).absolute uprobes starter
set).

This stuff is implemented in runtime/regs.c and
tapset/{i686,x86_64}/registers.stp, plus 1-2 lines each in
tapsets.cxx and translate.cxx.

I haven't implemented David Smith's suggestion of implementing
numbered args as $arg1, $arg2, etc., partly because without
dwarf (which is the whole point) "$arg1" doesn't tell you
enough about the arg to get the value in the form you want.
You need to know size and signedness.

Comments welcome.
Jim

Re: stap += dwarfless probing (phase 2)

[Jim Keniston]

On Tue, 2008-05-06 at 15:02 -0700, Jim Keniston wrote:
> This week I've updated the public "dwarfless" branch with support for
> the "Phase 2" features on i386 and x86_64:

I merged my dwarfless branch into the main branch today.

Per FChE's advice, I've moved almost all the register-lookup code that
was in runtime/regs.c into tapset/{i686,x86_64}/registers.stp.  The
[u_]register() and TYPE_arg() APIs remain the same.

Jim

> 
> a. Access to a probed function's arguments by number (since without
> dwarf you don't know their names).  This is implemented as a set of
> tapset functions with names of the form TYPE_arg(n), where TYPE is
> one of [u]int, [u]long, [u]longlong, pointer, s32, u32, s64, or u64;
> and n=1 for the first arg, 2 for the second, etc.
> 
> b. Access to the registers saved in pt_regs, by name --
> e.g., register("eax") to get regs->eax as a signed number, and
> u_register("eax") to get it as an unsigned number (i.e., zero-extended
> to 64 bits).
> 
> All this is documented in the NUMBERED FUNCTION ARGUMENTS and CPU
> REGISTERS sections of stapfuncs.5.in.
> 
> The only "test" I've checked in so far is tapset/nd_syscalls.stp.
> This is a copy of syscalls.stp with several aliases modified to use
> numbered arguments instead of named arguments.  (Look for "_arg".)
> The nd_syscall.* aliases produce the same results as the syscall.*
> aliases, and the eventual intent is for most or all of them to work
> even in the absence of dwarf.
> 
> According to my ad hoc testing, the *_arg(n) and [u_]register(name)
> functions can also be used when probing user apps (i.e., using
> Frank's old process(PID).statement(VADDR).absolute uprobes starter
> set).
> 
> This stuff is implemented in runtime/regs.c and
> tapset/{i686,x86_64}/registers.stp, plus 1-2 lines each in
> tapsets.cxx and translate.cxx.
> 
> I haven't implemented David Smith's suggestion of implementing
> numbered args as $arg1, $arg2, etc., partly because without
> dwarf (which is the whole point) "$arg1" doesn't tell you
> enough about the arg to get the value in the form you want.
> You need to know size and signedness.
> 
> Comments welcome.
> Jim