Re: [tip: x86/asm] x86/asm: Make ASM_CALL_CONSTRAINT conditional on frame pointers

[Josh Poimboeuf]

On Tue, Mar 04, 2025 at 11:56:27AM -0800, Josh Poimboeuf wrote:
> On Tue, Mar 04, 2025 at 08:57:13AM -1000, Linus Torvalds wrote:
> > On Tue, 4 Mar 2025 at 08:48, Linus Torvalds
> > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > Random ugly code, untested, special versions for different config options.
> > >
> > > __builtin_frame_address() is much more complex than just the old "use
> > > a register variable".
> > 
> > On the gcc bugzilla that hpa opened, I also note that Pinski said that
> > the __builtin_frame_address() is likely to just work by accident.
> > 
> > Exactly like the %rsp case.
> 
> Right, so they're equally horrible in that sense.
> 
> > I'd be much more inclined to look for whether marking the asm
> > 'volatile' would be a more reliable model. Or adding a memory clobber
> > or similar.
> 
> Believe me, I've tried those and they don't work.
> 
> > Those kinds of solutions would also hopefully not need different
> > sequences for different config options. Because
> > __builtin_frame_address() really *is* fundamentally fragile, and the
> > fact that frame pointers change behavior is a pretty big symptom of
> > that fragility.
> 
> While that may be theoretically true, the reality is that it produces
> better code for Clang.

BTW.  I confirmed that even the current version of ASM_CALL_CONSTRAINT
affects code generation for non-frame-pointer builds.

No matter what the ASM_CALL_CONSTRAINT implementation looks like, we
really don't want it affecting code generation for the ORC case.

So making ASM_CALL_CONSTRAINT empty for CONFIG_UNWINDER_ORC is a good
thing for code generation, regardless of the ASM_CALL_CONSTRAINT
implementation.

-- 
Josh