[Bug translator/17041] New: cast-scope.exp fails on s390x

[Bug translator/17041] New: cast-scope.exp fails on s390x

[jlebon at redhat dot com]

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

            Bug ID: 17041
           Summary: cast-scope.exp fails on s390x
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: jlebon at redhat dot com

The cast-scope.exp testcase fails on s390x as follow:

FAIL: cast-scope-m31
line 1: expected "function direct: {._M_dataplus={._M_p="Hello World!"}}"
Got "ERROR: read fault [man error::fault] at 0x000003ff7fbbfe14 (addr) near
identifier '$str' at
../../systemtap/testsuite/systemtap.base/cast-scope.stp:6:59"
    "WARNING: Number of errors: 1, skipped probes: 0"
    "WARNING: /root/systemtap/install/bin/staprun exited with status: 1"
    "Pass 5: run failed.  [man error::pass5]"

Here is cast-scope.cxx:

  1 #include "sys/sdt.h"
  2
  3 #include <string>
  4
  5 size_t
  6 length(const std::string& str)
  7 {
  8     int res, r;
  9     STAP_PROBE1(cast-scope, length, &str);
 10     r = str.length() * 2;
 11     STAP_PROBE(cast-scope, dummy); /* Just here to probe line +5. */
 12     res = r / 2;
 13     STAP_PROBE(cast-scope, dummy2); /* Just here prevent line reordering.
*/
 14     return res;
 15 }
 16
 17 int
 18 main()
 19 {
 20     std::string hello = "Hello World!";
 21     return 12 != length(hello);
 22 }

And here is cast-scope.stp:

  1 global function_string, statement_string, mark_string
  2
  3 probe process.function("length@cast-scope.cxx")
  4 {
  5   function_string .= sprintf("function direct: %s\n", $str$$)
  6   function_string .= sprintf("function cast: %s\n", @cast($str,
"std::string")$$)
  7 }
  8
  9 probe process.statement("length@cast-scope.cxx+4")
 10 {
 11   statement_string .= sprintf("statement direct: %s\n", $str$$)
 12   statement_string .= sprintf("statement cast: %s\n", @cast($str,
"std::string")$$)
 13 }
 14
 15 probe process.mark("length")
 16 {
 17   mark_string .= sprintf("mark cast: %s\n", @cast($arg1, "std::string")$$)
 18 }
 19
 20 probe end
 21 {
 22         # Why print the strings this way? cast-scope.exp expects the
 23         # output in a certain order.  If the probe addresses end up
 24         # the same, the process.function/process.mark probes might get
 25         # called in any order.
 26         #
 27         # So, we'll print the strings in a defined order.
 28         printf("%s", function_string);
 29         printf("%s", mark_string);
 30         printf("%s", statement_string);
 31 }

But even this simple script will fail with the same error:

  1 probe process.function("length@cast-scope.cxx")
  2 {
  3   printf("function cast: %s\n", @cast($str, "std::string")$$)
  4 }

It may be due to a bad calculated address for $str. This is the produced DWARF
code to retrieve $str:

{
  {
    uintptr_t addr;
  uintptr_t frame_base;
  { // DWARF expression: 0x92(11,208)
    {
      uintptr_t s0;
        s0 = fetch_register (11) + 208L;
      frame_base = s0;
    }
  }
    { // DWARF expression: 0x91(-108)
      {
        uintptr_t s0;
        s0 = frame_base + -108L;
        addr = s0;
      }
    }
    { // synthesized
    { uint32_t value = deref (4, addr); addr = value; }
    }
    STAP_RETVALUE = addr;
  }
  goto out;
if (0) goto deref_fault;
deref_fault:
  goto out;
}

So it retrieves the frame_base at register 11 + 208, then retrieves the address
of $str at frame_base - 108.

In comparison, retrieving the string works fine in GDB:

# g++ ../../systemtap/testsuite/systemtap.base/cast-scope.cxx -g -isystem../..
/systemtap/testsuite -isystem/root/systemtap/install/include -m31 -lm -o
cast-scope-m31.exe
# gdb cast-scope-m31.exe
(gdb) break length
Breakpoint 1 at 0x4007f2: file
../../systemtap/testsuite/systemtap.base/cast-scope.cxx, line 9.
(gdb) run
Starting program: /root/systemtap/build/testsuite/cast-scope-m31.exe

Breakpoint 1, length (str="Hello World!") at
../../systemtap/testsuite/systemtap.base/cast-scope.cxx:9
9           STAP_PROBE1(cast-scope, length, &str);
(gdb) print str
$1 = "Hello World!"
(gdb) print str._M_dataplus._M_p
$2 = 0xad4014 "Hello World!"
(gdb) print/x &str
$3 = 0x7fb761f0
(gdb) info regs
Undefined info command: "regs".  Try "help info".
(gdb) info registers
r0             0x0      0
r1             0x477fb761f0     307085402608
r2             0x7fb761f0       2142724592
r3             0x0      0
r4             0x8040086a       2151680106
r5             0x4700000000     304942678016
r6             0x4008fc 4196604
r7             0x7fb76318       2142724888
r8             0x0      0
r9             0x0      0
r10            0x37f    895
r11            0x7fb76120       2142724384
r12            0x4741205000     306035314688
r13            0x400900 4196608
r14            0x804008ac       2151680172
r15            0x7fb76120       2142724384
pc             0x4007f2 0x4007f2 <length(std::string const&)+14>
cc             0x2      2
(gdb)

Note how r11 indicates 0x7fb76120. Which means that to get the address of $str
(at 0x7fb761f0), GDB added to r11: 0x7fb761f0 - 0x7fb76120 = 0xD0 = 208. Doing
the same in SystemTap works:

  1 probe process.function("length@cast-scope.cxx")
  2 {
  3   addr = u_register("r11") + 208
  4   printf("function cast: %s\n", @cast(addr, "std::string")$$)
  5 }

# stap ../../systemtap/testsuite/systemtap.base/cast-scope.stp -c ./cast-scope
-m31.exe
function cast: {._M_dataplus={._M_p="Hello World!"}}
#

So it looks like we're not calculating the address of $str properly.

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

[Bug translator/17041] cast-scope.exp fails on s390x

[jlebon at redhat dot com]

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

--- Comment #1 from Jonathan Lebon <jlebon at redhat dot com> ---
Apologies, I forgot to add that this is on RHEL6 with git HEAD of SystemTap.

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

[Bug translator/17041] cast-scope.exp fails on s390x

[jistone at redhat dot com]

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

Josh Stone <jistone at redhat dot com> changed:

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

--- Comment #2 from Josh Stone <jistone at redhat dot com> ---
Just to summarize, we seem to have two issues:

1. The pointer has too many bits in 0x000003ff7fbbfe14.  We probably should be
checking if masks are needed in u_fetch_register().  (e.g. the x86_64 version
reads only 32-bit on compat processes.)  Alternately, if we want to allow the
possibility that some arch may have normal registers wider than the pointer
size, then we'll have to mask it at deref() instead.

2. The missing -108 in gdb is mysterious.  Jonathan showed me this eu-readelf
dump, which clearly looks like we need that:
 [  249d]      formal_parameter
               name                 (string) "str"
               decl_file            (data1) 1
               decl_line            (data1) 6
               type                 (ref4) [  24d3]
               location             (block1)
                [   0] fbreg -108

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

[Bug translator/17041] cast-scope.exp fails on s390x

[jistone at redhat dot com]

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

--- Comment #3 from Josh Stone <jistone at redhat dot com> ---
Scratch #2, fb-108 is the value of a reference to str, a pointer. 
Dereferencing that gives the actual address of str, which happens to be right
on top of fb.

So I think this is just a masking issue.

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

[Bug translator/17041] cast-scope.exp fails on s390x

[jistone at redhat dot com]

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

--- Comment #4 from Josh Stone <jistone at redhat dot com> ---
(In reply to Josh Stone from comment #3)
> Scratch #2, fb-108 is the value of a reference to str, a pointer. 
> Dereferencing that gives the actual address of str, which happens to be
> right on top of fb.

I should be more precise - str is a reference which really is at fb-108, and
the string it points to happens to be right at fb.

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

[Bug translator/17041] cast-scope.exp fails on s390x

[jlebon at redhat dot com]

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

Jonathan Lebon <jlebon at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Jonathan Lebon <jlebon at redhat dot com> ---
This is now fixed in commit 10bada5, which masks appropriately when in
compatibility mode:

    loc2c: make u_fetch_register() respect CONFIG_COMPAT

    If CONFIG_COMPAT is defined, then it is possible to be running 32/31-bit
    tasks on a 64-bit kernel. In such cases, we need to ensure that the
    values returned from u_fetch_register() are 32-bit friendly.

    Thus, we mask whatever pt_regs_fetch_register() returns.

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