[PATCH , all targets] Fix order of prologue instructions for varargs functions with -O0 and -m32

Luis Machado luisgpm@linux.vnet.ibm.com
Thu Feb 26 21:39:00 GMT 2009


On Thu, 2009-02-26 at 13:42 -0300, Luis Machado wrote:
> On Thu, 2009-02-26 at 16:32 +0000, Dave Korn wrote:
> > 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
> > 
> 
> The resulting asm code is as follows:
> 
>         stw 3,24(31)
>         stw 4,36(31)
>         stw 5,40(31)
>         stw 6,44(31)
>         stw 7,48(31)
>         stw 8,52(31)
>         stw 9,56(31)
>         stw 10,60(31)
>         bne 1,.L4
>         .loc 1 2 0
>         stfd 1,64(31)
>         stfd 2,72(31)
>         stfd 3,80(31)
>         stfd 4,88(31)
>         stfd 5,96(31)
>         stfd 6,104(31)
>         stfd 7,112(31)
>         stfd 8,120(31)
> 
> The debug info tells us r3 is at slot 24, instead of 120 as in the
> previous case.
> 
> Luis
> 

Actually r3 on slot 24 is strange. Let me do a new build here to make
sure. Had a number of binaries floating around.

Luis



More information about the Gcc-patches mailing list