Re: 64-syscall args on 32-bit vs syscall()

[Benjamin Herrenschmidt]

On Wed, 2010-03-17 at 09:18 +0000, Jamie Lokier wrote:
> Benjamin Herrenschmidt wrote:
> > Hence, apps that use the first form today because it works on x86 would
> > end up working at least on powerpc where they would have been otherwise
> > broken unless they used some arch specific #ifdef to do the second form.
> 
> I think what Ulrich is getting at is your change will break existing
> code which already does:
> 
> #ifdef __powerpc__
> 	syscall(SYS_foo, 0, my_64bit_arg);
> #else
> 	syscall(SYS_foo, my_64bit_arg);
> #endif
> 
> I don't know of any such code, but it might be out there.

No, the above "workaround" doesn't work. With the existing syscall()
definition, there is no difference between your two examples. In the
first case, you force a proper 64-bit aligment, but you are already off
by one register pair from the kernel expectation. In the second case,
gcc will imply one, which means that both your examples above will
result in my_64bit_arg in the -same- place, which is off by a register
pair from what the kernel expect.

IE. In the first case gcc will put SYS_foo in r3, 0 in r4, and
my_64bit_arg in r5 and r6. In the second case, gcc will put SYS_foo in
r3, won't care about r4, and will put the 64-bit arg in r5 and r6. Then,
glibc syscall() will shift r3 to r0, r3 to r4 etc... causing
my_64bit_arg to land in r4 and r5. But the kernel expects it in r3 and
r4.

The workaround that apps should use today is:

#if defined(__powerpc__) && WORDSIZE == 32
	syscall(SYS_foo, (u32)(my_64bit_arg >> 32), (u32)my_64bit_arg);
#else
	syscall(SYS_foo, my_64bit_arg);
#endif

And with my proposed change, both of the above will work. IE. gcc will
put the argument always in r5,r6 and the syscall() implementation will
always shift r5 to r3 and t6 to r4. 

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/