[Bug translator/13420] New: prologue detection fails for unoptimized 64bit cast-scope.exp testcase

[Bug translator/13420] New: prologue detection fails for unoptimized 64bit cast-scope.exp testcase

[mjw at redhat dot com]

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

             Bug #: 13420
           Summary: prologue detection fails for unoptimized 64bit
                    cast-scope.exp testcase
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap@sourceware.org
        ReportedBy: mjw@redhat.com
    Classification: Unclassified


cast-scope-m64 fails because prologue detection didn't pinpoint the right
location to pick up the arguments. Note that this only happens for 64-bit
builds without any optimization m64-O? and m32 are just fine.

The issue is that without optimization gcc will just put the incoming arguments
on the stack and then tell us through dwarf that they can be found on the stack
relative to the frame pointer:

 [  283b]    subprogram
             external             (flag) Yes
             name                 (strp) "length"
             decl_file            (data1) 1
             decl_line            (data1) 6
             MIPS_linkage_name    (strp) "_Z6lengthRKSs"
             type                 (ref4) [    70]
             low_pc               (addr) 0x00000000004007a4 <_Z6lengthRKSs>
             high_pc              (addr) 0x00000000004007bf <main>
             frame_base           (block1)               [   0] call_frame_cfa
             sibling              (ref4) [  2870]

 [  2861]      formal_parameter
               name                 (string) "str"
               decl_file            (data1) 1
               decl_line            (data1) 6
               type                 (ref4) [  2870]
               location             (block1)                 [   0] fbreg -24

But at the address where we probe the argument has not yet been moved on the
stack.

  4007a4:    55                       push    %rbp
  4007a5:    48 89 e5                 mov     %rsp,%rbp
  4007a8:    48 83 ec 10              sub     $0x10,%rsp
  4007ac:    48 89 7d f8              mov     %rdi,-0x8(%rbp)
  4007b0:    90                       nop
  4007b1:    48 8b 45 f8              mov     -0x8(%rbp),%rax
  4007b5:    48 89 c7                 mov     %rax,%rdi
  4007b8:    e8 93 fe ff ff           callq   0x400650
  4007bd:    c9                       leaveq
  4007be:    c3                       retq

searching for prologue of function 'length'
0x4007a4-0x4007bf@/home/mark/src/systemtap/testsuite/systemtap.base/cast-scope.cxx:6
checking line record
0x4007a4@/home/mark/src/systemtap/testsuite/systemtap.base/cast-scope.cxx:7
prologue found function 'length' (naked) = 0x4007a4
probe length@/home/mark/src/systemtap/testsuite/systemtap.base/cast-scope.cxx:6
process=/usr/local/build/systemtap-obj/testsuite/cast-scope-m64.exe
reloc=.absolute pc=0x4007a4

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

[Bug translator/13420] prologue detection fails for unoptimized 64bit cast-scope.exp testcase

[mjw at redhat dot com]

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

--- Comment #1 from Mark Wielaard <mjw at redhat dot com> 2011-11-21 12:43:12 UTC ---
BTW. GCC still doesn't emit real prologue markers in the line table.
See gcc/dwarf2out.c (dwarf2out_source_line):

  /* ??? TODO: Elide duplicate line number entries.  Traditionally,
     the debugger has used the second (possibly duplicate) line number
     at the beginning of the function to mark the end of the prologue.
     We could eliminate any other duplicates within the function.  For
     Dwarf3, we ought to include the DW_LNS_set_prologue_end mark in
     that second line number entry.  */

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

[Bug translator/13420] prologue detection fails for unoptimized 64bit cast-scope.exp testcase

[mjw at redhat dot com]

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

--- Comment #2 from Mark Wielaard <mjw at redhat dot com> 2011-11-29 17:11:32 UTC ---
Note that on powerpc both unoptimized -m32 and -m64 fail because of this issue.
Both have been kfailed.

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

[Bug translator/13420] prologue detection fails for unoptimized 64bit cast-scope.exp testcase

[mjw at redhat dot com]

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

--- Comment #3 from Mark Wielaard <mjw at redhat dot com> 2011-11-30 16:35:14 UTC ---
Filed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358

But note that even if we get location information it will likely say "not
available" at the start of the function where we place the probe. So then we
have to still do something (have a better prologue searcher?)

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

[Bug translator/13420] prologue detection fails for function parameters in unoptimized (-g only, no -O) code

[fche at redhat dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fche at redhat dot com
            Summary|prologue detection fails    |prologue detection fails
                   |for unoptimized 64bit       |for function parameters in
                   |cast-scope.exp testcase     |unoptimized (-g only, no
                   |                            |-O) code

--- Comment #4 from Frank Ch. Eigler <fche at redhat dot com> ---
We should attempt to work around the gcc bug in systemtap, but will need
to improve the prologue-searching heuristics already in effect.

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

[Bug translator/13420] prologue detection fails for function parameters in unoptimized (-g only, no -O) code

[fche at redhat dot com]

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

--- Comment #5 from Frank Ch. Eigler <fche at redhat dot com> ---
By the way, the .debug_line pattern for a toy program that demonstrates this:

% cat ~/foo.c 
int foo (int j)
{
printf("%d", j);
}

int main ()
{
int x = 5;
foo (x);
}

% gcc -g -o foo foo.c

% objdump -drs foo
[...]
0000000000400530 <foo>:
  400530:       55                      push   %rbp
  400531:       48 89 e5                mov    %rsp,%rbp
  400534:       48 83 ec 10             sub    $0x10,%rsp
  400538:       89 7d fc                mov    %edi,-0x4(%rbp)
  40053b:       8b 45 fc                mov    -0x4(%rbp),%eax
  40053e:       89 c6                   mov    %eax,%esi
  400540:       bf 00 06 40 00          mov    $0x400600,%edi
  400545:       b8 00 00 00 00          mov    $0x0,%eax
  40054a:       e8 c1 fe ff ff          callq  400410 <printf@plt>
  40054f:       c9                      leaveq 
  400550:       c3                      retq   

% readelf -w foo

 <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
    <2e>   DW_AT_external    : 1        
    <2e>   DW_AT_name        : foo      
    <32>   DW_AT_decl_file   : 1        
    <33>   DW_AT_decl_line   : 1        
    <34>   DW_AT_prototyped  : 1        
    <34>   DW_AT_type        : <0x6d>   
    <38>   DW_AT_low_pc      : 0x400530 
    <40>   DW_AT_high_pc     : 0x21     
    <48>   DW_AT_frame_base  : 1 byte block: 9c         (DW_OP_call_frame_cfa)
    <4a>   DW_AT_GNU_all_tail_call_sites: 1     
    <4a>   DW_AT_sibling     : <0x6d>   
 <2><4e>: Abbrev Number: 3 (DW_TAG_formal_parameter)
    <4f>   DW_AT_name        : j        
    <51>   DW_AT_decl_file   : 1        
    <52>   DW_AT_decl_line   : 1        
    <53>   DW_AT_type        : <0x6d>   
    <57>   DW_AT_location    : 2 byte block: 91 6c      (DW_OP_fbreg: -20)


[...]
 Line Number Statements:
  Extended opcode 2: set Address to 0x400530
  Special opcode 6: advance Address by 0 to 0x400530 and Line by 1 to 2
  Special opcode 160: advance Address by 11 to 0x40053b and Line by 1 to 3
  Advance PC by constant 17 to 0x40054c
  Special opcode 48: advance Address by 3 to 0x40054f and Line by 1 to 4
  Special opcode 36: advance Address by 2 to 0x400551 and Line by 3 to 7


It is at instruction 0x40053b at which the location becomes accurate
(after %edi, the incoming parameter, is saved to the stack).  stap's -P
algorithm stops looking at the special-opcode-6 part, where the line number
was incremented from 1 to 2, but the address wasn't changed.

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

[Bug translator/13420] prologue detection fails for function parameters in unoptimized (-g only, no -O) code

[jlebon at redhat dot com]

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

Jonathan Lebon <jlebon at redhat dot com> changed:

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

--- Comment #6 from Jonathan Lebon <jlebon at redhat dot com> ---
(In reply to Frank Ch. Eigler from comment #4)
> We should attempt to work around the gcc bug in systemtap, but will need
> to improve the prologue-searching heuristics already in effect.

One of the issues here is that our current heuristics rely on srclines to guess
the prologue end. This can cause problems, because line numbers are completely
independent of the prologue. For example, the following examples will cause
different behaviours when run through resolve_prologue_endings(), even though
the prologue ends at the same address in all cases (all variations of the
example given in comment 5):

---------------

// All on different lines
int foo (int j)
{
printf("%d", j);
}
// Result: thinks there's no prologue (naked), because the line advance to
// '{' is for the same addr (as we saw in comment 5). As a result, we get
// bad j values

// Opening brace on same line as decl
int foo (int j) {
printf("%d", j);
}
// Result: correctly finds the prologue end because the first line advance
// occurs at the same time as the addr change

// All on same line
int foo (int j) { printf("%d", j); }
// Result: correctly finds the prologue end (for the wrong reasons). It goes
// through the line records, and seeing no line advances, runs off the 
// function's highpc, so then goes back one step. What saves us here is the
// 0-line advance GCC adds to mark the end of the prologue. We normally ignore
// it since the lineno doesn't change. (The 0-line advance is also mentioned
// here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358#c1).

// Split lines
int foo (int j) { printf("%d", j);
printf("%d", j*2);
}
// Result: thinks the prologue end is at 0x4005f4, which actually corresponds
to
// the addr of the second printf call. Happens because that's where the first
// line advance occurs.

---------------

I think part of the solution here is to take advantage of the 0-line advance
when it is present (which I think only occurs when the prologue end doesn't
correspond to a line advance). This might mean simply always skipping the first
line record, regardless of actual line advances.

I'm also looking into GDB's way of handling the problem. It seems like there is
also arch-specific code to find specific opcodes in the prologue if line number
information fails to provide a clear answer (see e.g. amd64_analyze_prologue():
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/amd64-tdep.c;h=72d748e;hb=HEAD#l2129).
Depending on how often/likely lineno info can fail, we might not need to go
that far.

To be continued...

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

[Bug translator/13420] prologue detection fails for function parameters in unoptimized (-g only, no -O) code

[jlebon at redhat dot com]

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

Jonathan Lebon <jlebon at redhat dot com> changed:

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

--- Comment #7 from Jonathan Lebon <jlebon at redhat dot com> ---
I've updated the prologue searching algorithm so that we now pick up both
prologue_end markers (which clang emits) and 0-line advances (which GCC emits).
All the issues in comment 6 are now resolved, as well as the original
cast-scope testcase.

I also tested and tweaked it to work on older kernels/gccs (or at least to not
be less wrong than we were before). In some cases, we do even better there as
well!

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

[Bug translator/13420] prologue detection fails for function parameters in unoptimized (-g only, no -O) code

[jlebon at redhat dot com]

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

--- Comment #8 from Jonathan Lebon <jlebon at redhat dot com> ---
I forgot to mark down the related commits here: 02a15be and 7db8343 (and
previous).

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