[Bug debug/55586] Incorrect .debug_line section for function with variable number of arguments in PowerPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55586 Paul Smith changed: What|Removed |Added CC||psmith at gnu dot org --- Comment #4 from Paul Smith --- 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).
[Bug debug/55586] Incorrect .debug_line section for function with variable number of arguments in PowerPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55586 --- Comment #3 from Aleksandr Platonov 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55586 --- Comment #2 from Michael Meissner 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55586 David Edelsohn 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 2012-12-27 17:50:31 UTC --- Confirmed.
