[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <05C62769-A1DD-468C-9EF4-A7F78EC850AC@zytor.com>
Date: Tue, 04 Mar 2025 14:08:05 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Uros Bizjak <ubizjak@...il.com>, Josh Poimboeuf <jpoimboe@...nel.org>
CC: linux-kernel@...r.kernel.org,
tip-bot2 for Josh Poimboeuf <tip-bot2@...utronix.de>,
linux-tip-commits@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Brian Gerst <brgerst@...il.com>, x86@...nel.org
Subject: Re: [tip: x86/asm] x86/asm: Make ASM_CALL_CONSTRAINT conditional on frame pointers
On March 4, 2025 7:35:30 AM PST, Uros Bizjak <ubizjak@...il.com> wrote:
>
>
>On 4. 03. 25 01:35, H. Peter Anvin wrote:
>> On March 3, 2025 2:47:58 PM PST, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
>>> On Mon, Mar 03, 2025 at 02:45:50PM -0800, Josh Poimboeuf wrote:
>>>> On Mon, Mar 03, 2025 at 02:31:50PM -0800, H. Peter Anvin wrote:
>>>>>> +#ifdef CONFIG_UNWINDER_FRAME_POINTER
>>>>>> #define ASM_CALL_CONSTRAINT "r" (__builtin_frame_address(0))
>>>>>> +#else
>>>>>> +#define ASM_CALL_CONSTRAINT
>>>>>> +#endif
>>>>>>
>>>>>> #endif /* __ASSEMBLY__ */
>>>>>>
>>>>>
>>>>> Wait, why was this changed? I actually tested this form at least once
>>>>> and found that it didn't work under all circumstances...
>>>>
>>>> Do you have any more details about where this didn't work? I tested
>>>> with several configs and it seems to work fine. Objtool will complain
>>>> if it doesn't work.
>>>>
>>>> See here for the justification (the previous version was producing crap
>>>> code in Clang):
>>>
>>> Gah, that link doesn't work because I forgot to cc lkml.
>>>
>>> Here's the tip bot link:
>>>
>>> https://lore.kernel.org/all/174099976253.10177.12542657892256193630.tip-bot2@tip-bot2/
>>>
>>
>> One more thing: if we remove ASM_CALL_CONSTRAINTS, we will not be able to use the redzone in future FRED only kernel builds.
>
>Actually, GCC 15+ will introduce "redzone" clobber, so you will be able to write e.g.:
>
>void foo (void) { asm ("" : : : "cc", "memory", "redzone"); }
>
>Please see [1] and:
>
>+@...m "redzone"
>+The @code{"redzone"} clobber tells the compiler that the assembly code
>+may write to the stack red zone, area below the stack pointer which on
>+some architectures in some calling conventions is guaranteed not to be
>+changed by signal handlers, interrupts or exceptions and so the compiler
>+can store there temporaries in leaf functions. On targets which have
>+no concept of the stack red zone, the clobber is ignored.
>+It should be used e.g.@: in case the assembly code uses call instructions
>+or pushes something to the stack without taking the red zone into account
>+by subtracting red zone size from the stack pointer first and restoring
>+it afterwards.
>+
>
>[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
>
>Uros.
Very nice :)
Powered by blists - more mailing lists