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: Chris Metcalf <cmetcalf at mellanox dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 11 Jul 2016 16:36:43 -0400
- Subject: Re: [PATCH] Use SYSCALL_LL[64] to pass 64-bit value [BZ #20349]
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=cmetcalf at mellanox dot com;
- References: <20160711192653.GA4457@intel.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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.
--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com