[llvm-commits] [llvm-gcc-4.2] r93388 - in /llvm-gcc-4.2/trunk/gcc/testsuite/gcc.dg: ssp-1.c ssp-2.c

[Stuart Hastings]

On Jan 13, 2010, at 5:24 PM, Eric Christopher wrote:

>>>
>>
>> It's testing the stack-protector by clobbering its own stackframe.
>>
>
> Yep.
>
>> I'm about to commit some lexical-block debug stuff, and I had to  
>> change the order of declaration of variables.  That's not supposed  
>> to break anything, but...  lots of breakage.
>>
>
> Why did you have to change the order of declaration of variables?

I'm adding debug support for lexical blocks.  The LLVM interface I use  
has no "back-patching" ability; if the user wrote

	{ int a; blah(); ... { int b; blah(); ... { int c; blah(); ... }  
{ int d; ...

then I'm obliged to defer the declarations of b, c, and d until IR  
generation reaches those points in the code.  I cannot declare them  
all when I enter the function, as we do now.

If the user turns off debug info, we're supposed to generate the same  
code; accordingly, I must declare the variables in LLVM in the same  
order.

> I'd be surprised if someone wasn't relying on this behavior, even if  
> they're not supposed to.

My favorite test cases concerns a 96-bit struct composed of three  
floats; on x86_64, this is passed in two SSE registers.  If the callee  
has variable arguments :-) , the GCC x86_64 ABI stuff in i386.c  
generates a 128-bit store into a 96-bit local variable.  When I  
changed the order of declaration, some local int was clobbered.  This  
is a latent bug inside GCC; I'm confident a testcase could be created  
to demonstrate it.  The particular test case passes with our current  
GCC because that local int variable gets allocated in a register at - 
O0.  :-)

Note that my fix for the test case referenced above hasn't been  
committed yet.  The x86_64 ABI is somewhat complex, and the code is  
fragile.

stuart

>> For these two tiny test cases, GCC allocated the loop index in a  
>> register, even at -O0.  At -O0, LLVM put that variable on the stack.
>>
>> When I disturbed the order of declaration, the loop index moved  
>> *above* the array-to-clobber, the loop clobbered its own index, and  
>> then it looped indefinitely.
>>
>> (Note: my patch to change the order of declaration hasn't been  
>> committed yet.)
>>
>> Making the loop index static moves it far away from the  
>> clobbering.  Bill says we can replace the loop and its index  
>> variable with a call to memset().
>>
>> Do you have a strong opinion on this?
>
>
> I'd say static and haul it out of the function, but I'm still  
> concerned about the other.
>
> -eric