Bug 12536

Summary:	sdt v>=2 argument parsing can't parse '4+4(%esp)'
Product:	systemtap	Reporter:	Roland McGrath <roland>
Component:	translator	Assignee:	Stan Cox <scox>
Status:	RESOLVED FIXED
Severity:	normal	CC:	fche, systemtap
Priority:	P2
Version:	unspecified
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:

Description Roland McGrath 2011-03-03 01:26:55 UTC

systemtap-1.4-3.fc15.x86_64

I have the glibc with sdt probes installed, you can get it from http://koji.fedoraproject.org/scratch/roland/task_2877130/ (though that may expire in a few days).  Both glibc.x86_64 and glibc.i686 rpms from there are installed.

I used this script:

probe process("/lib*/libc.so.*").mark("*jmp*") { printf("%s(%p, %d) from PC %p: %s\n", $$name, $arg1, $arg2, $arg3, sprint_ubacktrace()); }

That was in -e, along with -d .../setjmp --ldd where .../setjmp is an i686 executable (and -c .../setjmp was at the end).

This produced:

WARNING: Downgrading SDT_V2 probe argument to dwarf, can't parse '4+4(%esp)': identifier '$arg2' at <input>:1:103

That argument appears in /lib/libc.so.6, which is the i686 DSO.

1. It says SDT_V2 when in fact this is v3.
2. I don't understand what "downgrading to dwarf" means anyway, since DWARF is of no help at all for the $arg2 syntax and what appears to happen is that the instance of the sdt probe that uses the problematic syntax just doesn't actually get probed at all.
3. The problem appears to be the 4+4 in the operand syntax.  Having simple arithmetic expressions in the displacements in operands, or in constant operands, is common in hand-written assembly (usually resulting from cpp macros used in the assembly, in fact).
4. The same error occurs when .../setjmp is an x86-64 executable instead, in which case the script actually works as intended because /lib/libc.so.6 is never used in the x86-64 process, and the probes in /lib64/libc.so.6 work fine.

Comment 1 Frank Ch. Eigler 2011-03-04 16:55:32 UTC

(In reply to comment #0)
> probe process("/lib*/libc.so.*").mark("*jmp*") { printf("%s(%p, %d) from PC %p:

> That was in -e, along with -d .../setjmp --ldd where .../setjmp is an i686
> executable (and -c .../setjmp was at the end).

(The -d / --ldd part should not be necessary.)
 
> This produced:
> WARNING: Downgrading SDT_V2 probe argument to dwarf, can't parse '4+4(%esp)':
> identifier '$arg2' at <input>:1:103
> 
> That argument appears in /lib/libc.so.6, which is the i686 DSO.
> 1. It says SDT_V2 when in fact this is v3.

OK, a misnomer.

> 2. I don't understand what "downgrading to dwarf" means anyway, since DWARF is
> of no help at all for the $arg2 syntax and what appears to happen is that the
> instance of the sdt probe that uses the problematic syntax just doesn't
> actually get probed at all.

For a C/C++ program with SDT_V2, if unexpected operand strings appear
in the .notes, stap does attempt to use DWARF to get at the (former) 
temporary copies of the parameters.  In SDT_V3, there is no such
temporary, so there won't be a DWARF record by those names anyway,
so we cannot fall back.

> 3. The problem appears to be the 4+4 in the operand syntax.  Having simple
> arithmetic expressions in the displacements in operands, or in constant
> operands, is common in hand-written assembly (usually resulting from cpp macros
> used in the assembly, in fact).

We should support some reasonable subset of such expressions.

> 4. The same error occurs when .../setjmp is an x86-64 executable instead, in
> which case the script actually works as intended because /lib/libc.so.6 is
> never used in the x86-64 process, and the probes in /lib64/libc.so.6 work fine.

Odd.

Comment 2 Stan Cox 2011-04-08 18:35:29 UTC

commit: e5b7b83f42
Allow offset to be +-N+-N+-N