Re: [PATCH] x86/ioperm: Use atomic64_inc_return() in ksys_ioperm()

[H. Peter Anvin]

On 10/26/24 16:28, H. Peter Anvin wrote:
> By any sane definition, the constraint should actually be an input 
> constraint on the frame pointer itself; something like:
>
> #define ASM_CALL_CONSTRAINT "r" (__builtin_frame_address(0))
>
> ... except that "r" really should be a %rbp constraint, but %rbp doesn't 
> seem to have a constraint letter. At least gcc 14.2 seems to do the 
> right thing anyway, though: __builtin_frame_address(0) seems to force a 
> frame pointer to have been created (even with -fomit-frame-pointer 
> specified, and in a leaf function), and the value is always passed in 
> %rbp (because why on Earth would it do it differently, when it is 
> sitting right there?)
cl
This also matches the "tell the compiler [and programmer] what we 
actually mean" issue that you have mentioned in other contexts.

Anyway, here is a simple test case that can be used to verify that this 
construct does indeed work; at least with gcc 14.2.1 and clang 18.1.8 
(the ones I ran a very quick test on).

It's simple enough that it is pretty straightforward to mess around with 
various modifications. So far I haven't been able to trip up the 
compilers this way.

	-hpa
unsigned long testit_reg(unsigned long x, unsigned long y)
{
    unsigned long z = x + y;
    unsigned long v;

    asm("# Frame pointer in %[fp]\n\tmov %[in],%[out]"
	: [out] "=r" (v)
	: [in] "r" (z), [fp] "r" (__builtin_frame_address(0)));

    return v;
}

unsigned long testit_buf(unsigned long x, unsigned long y)
{
    unsigned long z = x + y;
    unsigned long buffer[64];

    asm("# Frame pointer in %[fp]\n\tmov %[in],%[out]"
	: [out] "=m" (buffer)
	: [in] "r" (z), [fp] "r" (__builtin_frame_address(0)));

    return buffer[0];
}