On Sun, Apr 8, 2018 at 11:39 PM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> I see - so it's _not_ the same function call signature, but a wrapper with a
> sign-extended version, which is fair and useful. So on architectures where this
> matters there's type conversion and active code generated.
Exactly. Some architectures have that as part of their ABI.
On Powerpc, for example, when you pass an "int" argument, the ABI
specifies that you have to sign-extend the register in the caller to
64 bits.
And the generated code actually depends on that behavior, in that
maybe it first tests the 32 bit value, but then _uses_ the full 64
bits, knowing that the caller sign-extended it properly.
This is a problem with the system call interface, since the caller
isn't a trusted entity, and user space could pass an "int" value with
the high bits set to something that _isn't_ the sign-extended thing,
so then the compiler generates unsafe code.
On x86, this never happens, since x86 doesn't have that "hidden higher
bits matter" ABI model. So that part of the wrapper will be a complete
no-op. But some other architectures depend on it.
Linus
