Re: [tip: x86/asm] x86/asm: Make ASM_CALL_CONSTRAINT conditional on frame pointers
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [tip: x86/asm] x86/asm: Make ASM_CALL_CONSTRAINT conditional on frame pointers
- From: Josh Poimboeuf <jpoimboe@xxxxxxxxxx>
- Date: Tue, 4 Mar 2025 11:56:25 -0800
- Cc: Ingo Molnar <mingo@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, linux-tip-commits@xxxxxxxxxxxxxxx, "Peter Zijlstra (Intel)" <peterz@xxxxxxxxxxxxx>, Brian Gerst <brgerst@xxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, x86@xxxxxxxxxx
- In-reply-to: <CAHk-=whqPZjtH6VwLT3vL5-b3ONL2F83yEzxMMco+uFXe8CdKg@mail.gmail.com>
- References: <174099976188.10177.7153571701278544000.tip-bot2@tip-bot2> <CAHk-=wjSwqJhvzAT-=AY88+7QmN=U0A121cGr286ZpuNdC+yaw@mail.gmail.com> <Z8a66_DbMbP-V5mi@gmail.com> <CAHk-=wjRsMfndBGLZzkq7DOU7JOVZLsUaXnfjFvOcEw_Kd6h5g@mail.gmail.com> <CAHk-=wjc8jnsOkLq1YfmM0eQqceyTunLEcfpXcm1EBhCDaLLgg@mail.gmail.com> <20250304182132.fcn62i4ry5ndli7l@jpoimboe> <CAHk-=wjgGD1p2bOCOeTjikNKmyDJ9zH8Fxiv5A+ts3JYacD3fA@mail.gmail.com> <CAHk-=whqPZjtH6VwLT3vL5-b3ONL2F83yEzxMMco+uFXe8CdKg@mail.gmail.com>
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.
If the main argument is that it needs more testing, then sure, let's go
test more compiler versions.
--
Josh
[Index of Archives]
[Linux Stable Commits]
[Linux Stable Kernel]
[Linux Kernel]
[Linux USB Devel]
[Linux Video &Media]
[Linux Audio Users]
[Yosemite News]
[Linux SCSI]