Re: [PATCH 2/2] x86/asm: Fix inline asm call constraints for clang

[Ingo Molnar <mingo@kernel.org>]

* Josh Poimboeuf <jpoimboe@redhat.com> wrote:

> On Wed, Sep 20, 2017 at 10:32:43AM -0700, H. Peter Anvin wrote:
> > On 09/19/17 11:45, Josh Poimboeuf wrote:
> > > For inline asm statements which have a CALL instruction, we list the
> > > stack pointer as a constraint to convince GCC to ensure the frame
> > > pointer is set up first:
> > > 
> > >   static inline void foo()
> > >   {
> > >   	register void *__sp asm(_ASM_SP);
> > >   	asm("call bar" : "+r" (__sp))
> > >   }
> > > 
> > > Unfortunately, that pattern causes clang to corrupt the stack pointer.
> > > 
> > > There's actually an easier way to achieve the same goal in GCC, without
> > > causing trouble for clang.  If we declare the stack pointer register
> > > variable as a global variable, and remove the constraint altogether,
> > > that convinces GCC to always set up the frame pointer before inserting
> > > *any* inline asm.
> > > 
> > > It basically acts as if *every* inline asm statement has a CALL
> > > instruction.  It's a bit overkill, but the performance impact should be
> > > negligible.
> > > 
> > 
> > Again, probably negligible, but why do we need a frame pointer just
> > because we have a call assembly instruction?
> 
> It's frame pointer convention.  Without it, if dumping the stack from
> the called function, a function will get skipped in the stack trace.

BTW., could we perhaps relax this and simply phase out the frame pointer on x86, 
and simplify all our assembly in a cycle or two? ORC unwinder is working out very 
well so far. Live kernel patching can use ORC data just fine, and nothing else 
actually relies on frame pointers, right?

That would give one more register to assembly code.

I realize that we just rewrote a whole bunch of assembly code... but that was the 
price for ORC, in a way.

Thanks,

	Ingo