[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