Re: BUG: GCC-4.4.x changes the function frame on some functions

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, 19 Nov 2009, Richard Guenther wrote:
> 
> Note that I only can reproduce the issue with
> -mincoming-stack-boundary=2, not with -mpreferred-stack-boundary=2.

Since you can reproduce it with -mincoming-stack-boundary=2, I woul 
suggest just fixing mcount handling that way regardless of anything else. 
The current code generated by gcc is just insane - even for the case where 
you _want_ 16-byte stack alignment.

Instead crazy code like

>       push   %edi
>       lea    0x8(%esp),%edi
>       and    $0xfffffff0,%esp
>       pushl  -0x4(%edi)
>       push   %ebp
>       mov    %esp,%ebp
>       ...
>       call   mcount

the sane thing to do would be to just do it as

	push   %ebp
	mov    %esp,%ebp
	call   mcount
	and    $0xfffffff0,%esp

since

 - no sane 'mcount' implementation can ever care about 16-byte stack 
   alignment anyway, so aliging the stack before mcount is crazy.

 - mcount is special anyway, and is the only thing that cares about that 
   whole ebp/return address thing is mcount, and _all_ your games with 
   %edi are about that mcount thing.

IOW, once you as a compiler person understand that the 'mcount' call is 
special, you should have realized that all the work you did for it was 
totally pointless and stupid to begin with. 

You must already have that special mcount logic (the whole code to save a 
register early and push the fake mcount stack frame), so instead of _that_ 
special logic, change it to a different mcount special logic that 
associates the 'mcount' call with theframe pointer pushing. 

That will not only make the Linux kernel tracer happy, it will make all 
your _other_ users happier too, since you can generate smaller and more 
efficient code.

Admittedly, anybody who compiles with -pg probably doesn't care deeply 
about smaller and more efficient code, since the mcount call overhead 
tends to make the thing moot anyway, but it really looks like a win-win 
situation to just fix the mcount call sequence regardless.

> And you didn't provide us with a testcase either ... so please open a 
> bugzilla and attach preprocessed source of a file that shows the 
> problem, note the function it happens in and provide the command-line 
> options you used for building.
> 
> Otherwise it's going to be all speculation on our side.

See above - all you need to do is to just fix mcount calling.

Now, there is a separate bug that shows that you seem to over-align the 
stack when not asked for, and yes, since we noticed that I hope that 
Thomas and friends will fix that, but I think your mcount logic could (and 
should) be fixed as an independent sillyness.

			Linus