[Bug runtime/18083] New: listing_mode.exp fails on rhel6

[Bug runtime/18083] New: listing_mode.exp fails on rhel6

[mcermak at redhat dot com]

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

            Bug ID: 18083
           Summary: listing_mode.exp fails on rhel6
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

Created attachment 8168
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8168&action=edit
test logs

Commit e93efe2d0 (eliminate gcc5 warnings) introduced listing_mode.exp
failures. Some of them were later eliminated by commit 06902e9a6 (Adapt to
changed line numbers). Currently (at the f94683c76 time) some failures still
remain. Looking at the *first* failure in the x86_64 el6 log I see something
that looks like a real systemtap bug.

=======
executing: stap -l process.function("main").label("main_label")  -c
listing_mode
received:
"process("/root/mcermak-systemtap/systemtap/testsuite/listing_mode").function("main@./systemtap.base/listing_mode.c:37").label("main_label")"
expected:
"^process\("/root/mcermak-systemtap/systemtap/testsuite/listing_mode"\)\.function\("main@[^:]+:33"\)\.label\("main_label"\)$"
FAIL: listing_mode (process.function("main").label("main_label")  -c
listing_mode)
=======

The label actually *is* on line 33 in the test program, but line 37 refers to
it too:

=======
 29 int main(void) {
 30 
 31    globalvar = foo(globalvar);
 32    globalvar = libfoo(globalvar);
 33 main_label:
 34    STAP_PROBE1(main, mark, globalvar);
 35    while (1) {sleep(5000);}
 36    return 0;
 37    if (0) goto main_label;
 38 }
=======

So apparently systemtap reports wrong line number in this case.

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

[Bug runtime/18083] listing_mode.exp fails on rhel6

[mcermak at redhat dot com]

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

--- Comment #1 from Martin Cermak <mcermak at redhat dot com> ---
Created attachment 8169
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8169&action=edit
binary created using gcc-4.4.7-11.el6.x86_64

Attaching testing binary and verbose stap (version 2.8/0.161, commit
release-2.7-37-gf94683c76783 + changes) output:

=======
# stap -vvv -l 'process.function("main@listing_mode.c").label("main_label")' 
-c ./listing_mode

... stuff deleted ...

parse 'main@listing_mode.c', func 'main', file 'listing_mode.c'
focused on module '/root/work/tmp.nsVLz0WYTh/listing_mode' =
[0x400000-0x600b60, bias 0 file /root/work/tmp.nsVLz0WYTh/listing_mode ELF
machine |x86_64 (code 62)
focused on module '/root/work/tmp.nsVLz0WYTh/listing_mode'
selected source file '/root/work/tmp.nsVLz0WYTh/listing_mode.c'
selected function main
searching for prologue of function 'main'
0x4006d2-0x400701@/root/work/tmp.nsVLz0WYTh/listing_mode.c:29
checking line record 0x4006d2@/root/work/tmp.nsVLz0WYTh/listing_mode.c:29
checking line record 0x4006d6@/root/work/tmp.nsVLz0WYTh/listing_mode.c:31
prologue found function 'main' = 0x4006d6
probe main@/root/work/tmp.nsVLz0WYTh/listing_mode.c:37
process=/root/work/tmp.nsVLz0WYTh/listing_mode reloc=.absolute pc=0x4006f4
Eliding side-effect-free empty block operator '{' at <input>:1:67
WARNING: side-effect-free probe 'probe_2652': keyword at <input>:1:1
 source: probe process.function("main@listing_mode.c").label("main_label") {}
         ^
process("/root/work/tmp.nsVLz0WYTh/listing_mode").function("main@/root/work/tmp.nsVLz0WYTh/listing_mode.c:37")
/* pc=.absolute+0x4006f4 */ /* <-
process("/root/work/tmp.nsVLz0WYTh/listing_mode").function("main@/root/work/tmp.nsVLz0WYTh/listing_mode.c:37").label("main_label")
*/
chain[3]:
  [0]: 
        locations[1]:
          [0]:
process("/root/work/tmp.nsVLz0WYTh/listing_mode").function("main@/root/work/tmp.nsVLz0WYTh/listing_mode.c:37")
  [1]: 
        locations[1]:
          [0]:
process("/root/work/tmp.nsVLz0WYTh/listing_mode").function("main@/root/work/tmp.nsVLz0WYTh/listing_mode.c:37").label("main_label")
  [2]: 
        locations[1]:
          [0]:
process("./listing_mode").function("main@listing_mode.c").label("main_label")
process("/root/work/tmp.nsVLz0WYTh/listing_mode").function("main@/root/work/tmp.nsVLz0WYTh/listing_mode.c:37").label("main_label")
Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s)
using 207372virt/36008res/3828shr/32420data kb, in 0usr/10sys/8real ms.
Running rm -rf /tmp/stapYVnhGR
Spawn waitpid result (0x0): 0
=======

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

[Bug runtime/18083] listing_mode.exp fails on rhel6

[jlebon at redhat dot com]

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

Jonathan Lebon <jlebon at redhat dot com> changed:

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

--- Comment #2 from Jonathan Lebon <jlebon at redhat dot com> ---
Looks like it might be an old GCC bug that commit e93efe2 made apparent by
adding that goto statement. Here's an example:

$ nl main.c
     1    void main(void) {
     2       int x = 2;
     3    my_label:
     4       x += 2;
     5       printf("x = %d\n", x);
     6    }

$ gcc --version | head -n 1
gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)

$ gcc -w -g main.c -o main.f20

$ readelf -w main.f20 | grep DW_TAG_label -A 4
 <2><56>: Abbrev Number: 4 (DW_TAG_label)
    <57>   DW_AT_name        : (indirect string, offset: 0x0): my_label    
    <5b>   DW_AT_decl_file   : 1    
    <5c>   DW_AT_decl_line   : 3    
    <5d>   DW_AT_low_pc      : 0x40053f    
<...snip...>

Switching over to el5:

$ gcc --version | head -n 1
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)

$ gcc -w -g main.c -o main.el5

$ readelf -w main.el5 | grep DW_TAG_label -A 4
 <2><8f>: Abbrev Number: 4 (DW_TAG_label)
    <90>   DW_AT_name        : my_label    
    <99>   DW_AT_decl_file   : 1    
    <9a>   DW_AT_decl_line   : 3    
    <9b>   DW_AT_low_pc      : 0x4004a7    
<...snip...>

So it seems like all looks OK (in both GCCs, the DW_AT_decl_line is 3, which is
correct). Now let's add a goto statement:

$ nl main.c
     1    void main(void) {
     2       int x = 2;
     3    my_label:
     4       x += 2;
     5       printf("x = %d\n", x);
     6       goto my_label;
     7    }

$ readelf -w main.f20 | grep DW_TAG_label -A 4
 <2><56>: Abbrev Number: 4 (DW_TAG_label)
    <57>   DW_AT_name        : (indirect string, offset: 0x0): my_label    
    <5b>   DW_AT_decl_file   : 1    
    <5c>   DW_AT_decl_line   : 3    
    <5d>   DW_AT_low_pc      : 0x40053f    
<...snip...>

$ readelf -w main.el5 | grep DW_TAG_label -A 4
 <2><8f>: Abbrev Number: 4 (DW_TAG_label)
    <90>   DW_AT_name        : my_label    
    <99>   DW_AT_decl_file   : 1    
    <9a>   DW_AT_decl_line   : 6    
    <9b>   DW_AT_low_pc      : 0x4004a7    
<...snip...>

The f20 GCC is good, but the el5 GCC shows decl_line at 6 (where the goto
statement is) instead of 3. Note however that the low_pc is still correct. So
I'm thinking we could ignore decl_line for older GCCs and instead do a reverse
lookup to find the lineno corresponding to the low_pc. The only discrepancy is
that the lineno will be of the next statement, not where the label was defined
(e.g. in the above, 0x4004a7 corresponds to lineno 4, not 3). But it's still
much better than the wrong output.

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

[Bug runtime/18083] listing_mode.exp fails on rhel6

[wcohen at redhat dot com]

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

William Cohen <wcohen at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |wcohen at redhat dot com
         Resolution|---                         |WORKSFORME

--- Comment #3 from William Cohen <wcohen at redhat dot com> ---
RHEL6 is no longer supported.

Check to see if this is a problem on x86_64 RHEL8/9.  This particular test is
passing on both x86_64 RHEL8 and RHEL9.

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