Support six-argument syscalls from C for 32-bit x86, use generic lowlevellock-futex.h (bug 18138)

[Florian Weimer]

On 03/23/2015 10:47 PM, Joseph Myers wrote:
> On Mon, 23 Mar 2015, Richard Henderson wrote:
> 
>> On 03/20/2015 05:28 PM, Joseph Myers wrote:
>>> +#define INTERNAL_SYSCALL_MAIN_6(name, err, arg1, arg2, arg3,		\
>>> +				arg4, arg5, arg6)			\
>>> +  struct libc_do_syscall_args _xv =					\
>>> +    {									\
>>> +      (int) (arg1),							\
>>> +      (int) (arg5),							\
>>> +      (int) (arg6)							\
>>> +    };									\
>>> +    asm volatile (							\
>>> +    "movl %1, %%eax\n\t"						\
>>> +    "call __libc_do_syscall"						\
>>> +    : "=a" (resultvar)							\
>>> +    : "i" (__NR_##name), "c" (arg2), "d" (arg3), "S" (arg4), "D" (&_xv) \
>>> +    : "memory", "cc")
>>
>> Is this really so much better than
>>
>> extern int __attribute__((regcall(3))) attribute_hidden
>> __libc_do_syscall(int nr_eax, int arg3_edx, int arg2_ecx, int arg1_ebx,
>>                   int arg4_esi, int arg5_edi, int arg6_ebp);
>>
>> and performing the call itself in C?  It's only one more register you need to
>> read from the stack in the function, but it avoids the compiler seeing a leaked
>> pointer to the caller's stack frame.  The later could well influence
>> optimization negatively.
> 
> I don't see the leaked pointer as relevant to optimization.  GCC knows 
> that a pointer to one stack object can't be a basis for a pointer to 
> another stack object, and that the variable's lifetime ends at end of 
> scope.

Your code causes instrumentation with -fstack-protector-strong (because
there is an addressable local variable), and the plain function call
wouldn't.

-- 
Florian Weimer / Red Hat Product Security