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

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

[roland at gnu dot org]

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

           Summary: sdt v>=2 argument parsing can't parse '4+4(%esp)'
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: scox@redhat.com
        ReportedBy: roland@gnu.org
                CC: systemtap@sources.redhat.com


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.

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

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

[Roland McGrath]

I filed this PR when I hit problems trying to develop a test case for the
new setjmp/longjmp probes.  The probe argument in glibc is not going to
change, so I think this needs to be fixed before a test case can pass for
i686.  I think I'll try to develop the full test suite case and get it
working on x86-64, where there won't be this problem because it doesn't
happen to come up in those probe arguments.

For reference, here is the program I was using when I filed that PR.


#include <stdio.h>
#include <setjmp.h>

struct env
{
  jmp_buf jmp;
};

struct env saved;

void __attribute__ ((noinline))
bar (struct env *env, int x)
{
  if (x == 0)
    siglongjmp (env->jmp, 1);
}

void __attribute__ ((noinline))
foo (void)
{
  if (sigsetjmp (saved.jmp, 1) == 0)
    {
      puts ("foo the first time");
      bar (&saved, 0);
    }
  else
    puts ("foo the second time");
}

int
main (void)
{
  foo ();
  return 0;
}

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

[fche at redhat dot com]

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.