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:
