[Bug translator/12536] sdt v>=2 argument parsing can't parse '4+4(%esp)'

["fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12536

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fche at redhat dot com

--- Comment #1 from Frank Ch. Eigler <fche at redhat dot com> 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.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.