On Thu, 19 Nov 2009, Thomas Gleixner wrote:
>
> standard function start:
>
> push %ebp
> mov %esp, %ebp
> ....
> call mcount
>
> modified function start on a handful of functions only seen with gcc
> 4.4.x on x86 32 bit:
>
> push %edi
> lea 0x8(%esp),%edi
> and $0xfffffff0,%esp
> pushl -0x4(%edi)
> push %ebp
> mov %esp,%ebp
> ...
> call mcount
That's some crazy sh*t anyway, since we don't _want_ the stack to be
16-byte aligned in the kernel. We do
KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=2)
why is that not working?
So this looks like a gcc bug, plain and simple.
> This modification leads to a hard to solve problem in the kernel
> function graph tracer which assumes that the stack looks like:
>
> return address
> saved ebp
Umm. But it still does, doesn't it? That
pushl -0x4(%edi)
push %ebp
should do it - the "-0x4(%edi)" thing seems to be trying to reload the
return address. No?
Maybe I misread the code - but regardless, it does look like a gcc code
generation bug if only because we really don't want a 16-byte aligned
stack anyway, and have asked for it to not be done.
So I agree that gcc shouldn't do that crazy prologue (and certainly _not_
before calling mcount anyway), but I'm not sure I agree with that detail
of your analysis or explanation.
Linus
