Re: PATCH: Add LOAD_ARG[1-6]_TYPE and x32 posix_fallocate.c

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Mon, May 21, 2012 at 2:47 PM, Roland McGrath <roland@hack.frob.com> wrote:
>> The only problem is off_t, which is int64_t for both
>> x32 and x86-64. ?Again, it makes no difference between
>> unsigned long long int and long long int for both x32 and x86-64.
>> There are no other system calls in C which has int64_t for
>> arguments.
>
> So then using 'unsigned long long int' in the syscall macros would be fine.

Yes, but for x32, we generate an REX byte which isn't
needed.

>> For those system calls which take uint64_t, long is fine for x32 since
>> casting from unsigned long to long will zero-extend to uint64.
>
> This doesn't make any sense. ?uint64_t is 'unsigned long long int'.
> Casting it to 'long int' will truncate to 32 bits.

All for those uint64_t cases are size_t, which is uint32_t in user space and
uint64_t in kernel, for example:

ssize_t read(int fd, void *buf, size_t count);

The upper 32 bits are always zero for x32.  There are no other uint64_t.

>> So using ?'unsigned long long int' isn't necessary for neither
>> x32 nor x86-64.
>
> As it stands today, the syscall macros use 'long int'; on x32, this
> truncates to 32 bits, which breaks all 64-bit arguments. ?(If that weren't

Only off_t.

> the case, you never would have proposed the kludge for posix_fallocate.)
> If we changed it to 'long long int' then pointer arguments would get
> sign-extended, which would break everything. ?So 'unsigned long long int'
> is the option that makes no difference to x86_64, makes x32 pointer
> arguments work, and makes x32 int64_t arguments work. ?Am I confused?
>

That means we will generate "movq" instead of "movl" on user
uint32_t/kernel uint64_t arguments with a REX byte which x32
doesn't need.

-- 
H.J.