On Tue, 4 Mar 2025 at 08:21, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > I'm utterly confused, what are these new problems you're referring to? Random ugly code, untested, special versions for different config options. > And how specifically is this more fragile? 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". > AFAICT, there was one known bug before the patches. Now there are zero > known bugs. Big surprise - since it hasn't been tested on very many compiler versions. > I'm excited to hear we can get rid of a lot of old GCC cruft, but this > has nothing to do with the compiler version. > > It's needed for CONFIG_UNWINDER_FRAME_POINTER, for all compiler > versions. Otherwise the callee may skip the frame pointer setup before > doing the call. So you claim. But the original ASM_CALL_CONSTRAINT code was for a gcc bug that was reportedly fixed in gcc-7.1 So is it *actually* required? Because in my testing, gcc doesn't move inline asms to before the frame pointer setup any more. But I actually didn't base my arguments on my very limited testing, but on our own documented history of this thing. In your own words from 8 years go in commit f5caf621ee35 ("x86/asm: Fix inline asm call constraints for Clang"), just having the register variable makes the problem go away: With GCC 7.2, however, GCC's behavior has changed. It now changes its behavior based on the conversion of the register variable to a global. That somehow convinces it to *always* set up the frame pointer before inserting *any* inline asm. (Therefore, listing the variable as an output constraint is a no-op and is no longer necessary.) and the whole ASM_CALL_CONSTRAINT thing is just unnecessary. So I repeat: why are we making the code worse? Linus
![]() |