[patch RFC] SH: -fstack-protector support

Joern RENNECKE joern.rennecke@st.com
Wed Jul 20 14:19:00 GMT 2005


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.



More information about the Gcc-patches mailing list