This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH , all targets] Fix order of prologue instructions for varargs functions with -O0 and -m32
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: luisgpm at linux dot vnet dot ibm dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 26 Feb 2009 16:32:24 +0000
- Subject: Re: [PATCH , all targets] Fix order of prologue instructions for varargs functions with -O0 and -m32
- References: <1235662822.14604.13.camel@gargoyle>
Luis Machado wrote:
> When built with -O0 and -m32, we get the following asm as output:
>
> stw 4,28(31)
> stw 5,32(31)
> stw 6,36(31)
> stw 7,40(31)
> stw 8,44(31)
> stw 9,48(31)
> stw 10,52(31)
>>>>>> Debug info tells us r3 is already saved at this point
> bne 1,.L2
> stfd 1,56(31)
> stfd 2,64(31)
> stfd 3,72(31)
> stfd 4,80(31)
> stfd 5,88(31)
> stfd 6,96(31)
> stfd 7,104(31)
> stfd 8,112(31)
>>>>>> End of prologue/Beginning of function
> stw 3,120(31)
>
> As we can see, r3 isn't saved to the stack until later in the process,
> but the debugging information tells us r3 should already be on slot 120
> right before the branch instruction. This prevents GDB from getting the
> correct value for the last named argument of a variadic function right
> upon entering it.
Wouldn't it be simpler to fix the debug info generation to be correct,
rather than risk tampering with the code generation on every platform in the
world? Also, subject line updated; you're going to need a global reviewer for
the change to function.c, not an rs6000 backend maintainer.
What actual changes result to the generated debug and assembly after your
patch, how does it look then?
cheers,
DaveK