[Bug debug/55586] New: Incorrect .debug_line section for function with variable number of arguments in PowerPC

[Bug debug/55586] New: Incorrect .debug_line section for function with variable number of arguments in PowerPC

[pam at oktetlabs dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55586

             Bug #: 55586
           Summary: Incorrect .debug_line section for function with
                    variable number of arguments in PowerPC
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: pam@oktetlabs.ru


This is PowerPC problem.

Example:
Code:
int
my_function(int x, ...)
{
    return x+1;
}


dwarfdump for this code shows the following .debug_line section:
...
0x01800490  [   3, 0] NS uri: "1.c"
0x018004bc  [   3, 0] NS
0x018004e0  [   4, 0] NS
...

Disassembler in GDB shows:
(gdb) disass my_function
Dump of assembler code for function my_function:
   0x01800490 <+0>:    stwu    r1,-120(r1)
   0x01800494 <+4>:    stw     r31,116(r1)
   0x01800498 <+8>:    mr      r31,r1
   0x0180049c <+12>:    stw     r4,12(r31)
   0x018004a0 <+16>:    stw     r5,16(r31)
   0x018004a4 <+20>:    stw     r6,20(r31)
   0x018004a8 <+24>:    stw     r7,24(r31)
   0x018004ac <+28>:    stw     r8,28(r31)
   0x018004b0 <+32>:    stw     r9,32(r31)
   0x018004b4 <+36>:    stw     r10,36(r31)
   0x018004b8 <+40>:    bne     cr1,0x18004dc <my_function+76>
   0x018004bc <+44>:    stfd    f1,40(r31)
   0x018004c0 <+48>:    stfd    f2,48(r31)
   0x018004c4 <+52>:    stfd    f3,56(r31)
   0x018004c8 <+56>:    stfd    f4,64(r31)
   0x018004cc <+60>:    stfd    f5,72(r31)
   0x018004d0 <+64>:    stfd    f6,80(r31)
   0x018004d4 <+68>:    stfd    f7,88(r31)
   0x018004d8 <+72>:    stfd    f8,96(r31)
   0x018004dc <+76>:    stw     r3,104(r31)
....

So at try to set breakpoint at my_function() function, GDB sets breakpoint at
address 0x018004bc, which is not correct because this address is unreachable if
we do not pass floating point arguments to my_function().

[Bug debug/55586] Incorrect .debug_line section for function with variable number of arguments in PowerPC

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55586

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-12-27
                 CC|                            |bergner at gcc dot gnu.org,
                   |                            |dje at gcc dot gnu.org,
                   |                            |meissner at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #1 from David Edelsohn <dje at gcc dot gnu.org> 2012-12-27 17:50:31 UTC ---
Confirmed.

[Bug debug/55586] Incorrect .debug_line section for function with variable number of arguments in PowerPC

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55586

--- Comment #2 from Michael Meissner <meissner at gcc dot gnu.org> 2013-02-07 23:49:34 UTC ---
As far as I can tell, it is a bug in earlier versions of GDB, and not in the
compiler.

Due to the ABI's, it will only show up in 32-bit powerpc with an older GDB. 
The 64-bit powerpc has a completely different ABI, and for stdarg functions, it
does not pass the values in floating point registers, and it doesn't use CR6 to
indicate that the floating point values were passed.  So there isn't a jump,
etc.

I tested GCC 4.8, 4.7 and found that they essentially generated the same code
for the debugging information.  On my SLES 10 system, I even used the system
compiler which is 4.1.2 based, and it generated the same debug code.  If I used
a GDB that was 7.3 or newer (SLES 11 SP2, IBM Advance Toolchain 5.0, etc.) and
put a breakpoint on the my_function, the debugger puts the breakpoint on the
STWU instruction, and it hits the breakpoint.

If I use the system debugger on SLES 10 which is version 7.1, the debugger
skips the function start, and puts the breakpoint on the first STFD instruction
as you mention, and it won't hit the breakpoint unless you pass floating point
values in the floating point registers.

Here is the assembler output from one of the compilers for -O -m32.  Note,
there is a .loc before the first instruction at line 9 (the beginning of the
function).

my_function:
.LFB12:
        .file 1 "bug-55586.c"
        .loc 1 9 0
.LVL0:
        stwu 1,-128(1)
.LCFI0:
        mflr 0
.LCFI1:
        stw 31,124(1)
.LCFI2:
        stw 0,132(1)
.LCFI3:
        stw 4,28(1)
        stw 5,32(1)
        stw 6,36(1)
        stw 7,40(1)
        stw 8,44(1)
        stw 9,48(1)
        stw 10,52(1)
        bne 1,.L2
        .loc 1 9 0
        stfd 1,56(1)
        stfd 2,64(1)
        stfd 3,72(1)
        stfd 4,80(1)
        stfd 5,88(1)
        stfd 6,96(1)
        stfd 7,104(1)
        stfd 8,112(1)
.L2:

[Bug debug/55586] Incorrect .debug_line section for function with variable number of arguments in PowerPC

[pam at oktetlabs dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55586

--- Comment #3 from Aleksandr Platonov <pam at oktetlabs dot ru> 2013-02-11 08:00:41 UTC ---
(In reply to comment #2)
> As far as I can tell, it is a bug in earlier versions of GDB, and not in the
> compiler.
> 
> a GDB that was 7.3 or newer (SLES 11 SP2, IBM Advance Toolchain 5.0, etc.) and
> put a breakpoint on the my_function, the debugger puts the breakpoint on the
> STWU instruction, and it hits the breakpoint.
> 
I can reproduce this problem with GDB 7.5.
I do not think that this is GDB problem, just because GDB should skip function
prologue according with debug information (if debug information does not exist
then GDB will analyze instructions and breakpoint will be set at correct
address)

GCC creates 2 elements in .debug_line section for the same source line number
and GDB sets breakpoint at address from the second .debug_line section element.
I think this behavior of GDB is not a bug.

Could we avoid creation of the second .debug_line section element or just
associate it with the next source line?

[Bug debug/55586] Incorrect .debug_line section for function with variable number of arguments in PowerPC

[psmith at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55586

Paul Smith <psmith at gnu dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |psmith at gnu dot org

--- Comment #4 from Paul Smith <psmith at gnu dot org> ---
See also https://sourceware.org/bugzilla/show_bug.cgi?id=16280 which has a
repro case for C++ inline functions on x86_64 (very latest GCC 4.8.2 and GDB
7.6.1 releases).