On Thu, Nov 19, 2009 at 6:59 PM, Steven Rostedt <rost...@goodmis.org> wrote: > On Thu, 2009-11-19 at 09:39 -0800, Linus Torvalds wrote: > >> > 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? > > Yes that is what it is doing. The problem we have is that it is putting > into the frame pointer a "copy" of the return address, and not the > actual pointer. Which is fine for the function tracer, but breaks the > function graph tracer (which is a much more powerful tracer). > > Technically, this is all that mcount must have. And yes, we are making > an assumption that the return address in the frame pointer is the one > that will be used to leave the function. But the reason for making this > copy just seems to be all messed up. > > I don't know if the ABI says anything about the return address in the > frame pointer must be the actual return address. But it would be nice if > the gcc folks would let us guarantee that it is.
Note that I only can reproduce the issue with -mincoming-stack-boundary=2, not with -mpreferred-stack-boundary=2. 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. Thanks, Richard.
