This is the mail archive of the
mailing list for the glibc project.
Re: PATCH: Add LOAD_ARG[1-6]_TYPE and x32 posix_fallocate.c
On Mon, May 21, 2012 at 2:47 PM, Roland McGrath <email@example.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
> 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
>> 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
> 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