[Bug dyninst/23291] New: powerpc SDT argument constraint change caused dyninst mode regression

[Bug dyninst/23291] New: powerpc SDT argument constraint change caused dyninst mode regression

[mcermak at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23291

            Bug ID: 23291
           Summary: powerpc SDT argument constraint change caused dyninst
                    mode regression
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dyninst
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com
  Target Milestone: ---

Commit 50f2ef5be3c24b3fe9eb4c9abc386d8dbc3b953a caused a regression on powerpc
in --dyninst mode:

=======
commit 50f2ef5be3c24b3fe9eb4c9abc386d8dbc3b953a (HEAD, refs/bisect/bad)

    powerpc: Change SDT argument constraint

    With the 'o' memory constraint, any memory operand which
    has an offsettable address is allowed. However, for some
    architectures such as powerpc, this allows operands like
    the ones shown below in the readelf output from Fedora 26
    to be generated.

      $ readelf -n /lib64/libc.so.6 | grep memory_mallopt_mmap_max -A2 -B2
        stapsdt              0x0000006c     NT_STAPSDT (SystemTap probe
descriptors)
          Provider: libc
          Name: memory_mallopt_mmap_max
          Location: 0x00000000000a0274, Base: 0x00000000001ccb90, Semaphore:
0x0000000000000000
          Arguments: -4@9 -4@.LANCHOR0+44@toc@l(8) -4@.LANCHOR0+52@toc@l(7)

    The second and third argument shown above are both having
    operands which are pointers to static data anchors. Since
    these static anchors are not included in the symbol table,
    they cannot be resolved from the binary itself. So, such
    arguments cannot be read via their corresponding markers.

    Using the 'Z' memory constraint instead solves this issue
    as it will only allow a memory operand that is an indexed
    or indirect from a register.

    So, for powerpc, we set STAP_SDT_ARG_CONSTRAINT to 'nZr'
    but keep it as 'nor' for all other architectures.
=======

regressed behaviour:

=======
 7.5 Server ppc64 # stap --dyninst -p4
systemtap/testsuite/buildok/stap_staticmarkers-detailed.stp 
WARNING: Can't parse SDT_V3 operand '10,9' [man error::sdt]: identifier '$arg1'
at /usr/local/share/systemtap/tapset/stap_staticmarkers.stp:174:28
 source:        path = user_string_quoted($arg1)
                                          ^
semantic error: while processing probe
process("/usr/local/bin/stap").statement(0x101cbb40) from:
process("/usr/local/bin/stap").statement(0x101cbb40) from:
process("/usr/local/bin/stap").mark("cache__clean") from: stap.cache_clean
from: stap.cache_clean

semantic error: unable to find local 'arg1', [man error::dwarf] dieoffset
0x91377d in /usr/local/bin/stap, near pc 0x101cbb40 in <unknown>
../systemtap/cache.cxx (alternatives: $j)): identifier '$arg1' at :174:28
        source:         path = user_string_quoted($arg1)
                                                  ^

semantic error: SDT asm not understood, requires debuginfo [man error::sdt]:
identifier '$arg1' at :174:28
        source:         path = user_string_quoted($arg1)
                                                  ^

Pass 2: analysis failed.  [man error::pass2]
 7.5 Server ppc64 #
 7.5 Server ppc64 #
 7.5 Server ppc64 #
 7.5 Server ppc64 # eu-readelf -n /usr/local/bin/stap | grep 0x101cbb40 -C1
  stapsdt               49  Version: 3
    PC: 0x101cbb40, Base: 0x102f5720, Semaphore: 0
    Provider: stap, Name: cache__clean, Args: '8@10,9'
 7.5 Server ppc64 # 
=======

-- 
You are receiving this mail because:
You are the assignee for the bug.