Re: [patch RFC] SH: -fstack-protector support

[Joern RENNECKE <joern dot rennecke at st dot com>]

Jakub Jelinek wrote:

> On Wed, Jul 20, 2005 at 02:57:34PM +0100, Joern RENNECKE wrote:
>  
>
> > > It seems a typo in the stack_protect_test documentation.
> > >
> > > This pattern, if defined, compares a @code{Pmode} value from the
> > > memory in operand 1 with the memory in operand 0 without leaving the
> > > value in a register afterward and branches to operand 2 if the values
> > > weren't equal.
> > >    ^^^
> > > The last line should be "were equal", shouldn't it?  i386 and ppc
> > > implementations do so.
> > >
> > >
> > >      
> > That is a likely explanation, but till we get clarification from Jacub, we
> > also have to consider the possibility that it was a bug in the original
> > implementation that was copied to the ppc port.
> >    
>
> operand2 is label before the call to __stack_chk_fail{,_local}, so of course
>  
No, it's after the call.

> the pattern needs to jump to that label if the 2 values (canary value
> in __stack_chk_guard resp. in TLS area and the stack slot to which
> that value was saved in the prologue) are NOT equal.
> So IMHO the documentation is correct and what i386 and ppc (and other
> platforms) implement is also ok, say on i386 a trivial testcase
>  
They jump to operand2 if equal.

> with -m32 -fstack-protector -O2 -fpic leads to:
> void bar (char *) __attribute__((visibility ("hidden")));
> void foo (void)
> {
>  char buf[64];
>  bar (buf);
> }
>
> .globl foo
>        .type   foo, @function
> foo:
>        pushl   %ebp
>        movl    %esp, %ebp
>        subl    $100, %esp
>        movl    %gs:20, %eax
>        movl    %eax, -4(%ebp)
>        xorl    %eax, %eax
>        leal    -68(%ebp), %eax
>        pushl   %eax
>        call    bar
>        addl    $16, %esp
>        movl    -4(%ebp), %eax
>        xorl    %gs:20, %eax
>        jne     .L5
>        leave
>        ret
> .L5:
>        call    __stack_chk_fail_local
>        .size   foo, .-foo
>
> 	Jakub
>  
That's the code that you get after the optimizers had their go at the code.
but the code that is initially expanded looks different.