This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Use SYSCALL_LL[64] to pass 64-bit value [BZ #20349]
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Chris Metcalf <cmetcalf at mellanox dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 11 Jul 2016 14:04:49 -0700
- Subject: Re: [PATCH] Use SYSCALL_LL[64] to pass 64-bit value [BZ #20349]
- Authentication-results: sourceware.org; auth=none
- References: <20160711192653.GA4457@intel.com> <4067a9a1-f91a-3820-5878-b906a3f0f76d@mellanox.com>
On Mon, Jul 11, 2016 at 1:36 PM, Chris Metcalf <cmetcalf@mellanox.com> wrote:
> On 7/11/2016 3:26 PM, H.J. Lu wrote:
>>
>> SYSCALL_LL/SYSCALL_LL64 should be used to pass 64-bit value to system
>> calls.
>
>
> What problem are you trying to solve?
>
> SYSCALL_LL and LO_HI_LONG are different on big-endian systems. In this
> case, LO_HI_LONG is correct, since the kernel API is "unsigned long pos_l,
> unsigned long pos_h". SYSCALL_LL won't do the right thing.
>
> __ALIGNMENT_ARG introduces an extra dummy arguments to be inserted before
> a 64-bit value split into two 32-bit registers, if required by the platform.
> Since preadv/pwritev explicitly use split arguments to construct a 64-bit
> loff_t, __ALIGNMENT_ARG will just add a random inappropriate dummy arg
> to an API that doesn't need one.
>
> I reviewed the casting for LO_HI_LONG and it looks OK; I initially was
> wondering whether losing the "val >> 31, val" semantics from SYSCALL_LL()
> might have been problematic, but it seems like LO_HI_LONG should generate
> the same results.
>
/* Provide a macro to pass the off{64}_t argument on p{readv,writev}{64}. */
#define LO_HI_LONG(val) \
(long) (val), \
(long) (((uint64_t) (val)) >> 32)
is wrong for __ASSUME_WORDSIZE64_ILP32 platform.
--
H.J.