This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH 2/9] Tilera (and Linux asm-generic) support for glibc
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Chris Metcalf <cmetcalf at tilera dot com>
- Cc: libc-ports at sourceware dot org, Arnd Bergmann <arnd at arndb dot de>, Linas Vepstas <linas at codeaurora dot org>, Guan Xuetao <gxt at mprc dot pku dot edu dot cn>, Jonas Bonn <jonas at southpole dot se>, Chen Liqin <liqin dot chen at gmail dot com>
- Date: Sat, 5 Nov 2011 01:51:46 +0000 (UTC)
- Subject: Re: [PATCH 2/9] Tilera (and Linux asm-generic) support for glibc
- References: <201111031955.pA3Jt3sC024069@farm-0002.internal.tilera.com> <201111032001.pA3K1oGX024633@farm-0002.internal.tilera.com>
On Thu, 3 Nov 2011, Chris Metcalf wrote:
> +/* 64-bit libc uses the kernel's 'struct stat', accessed via the
> + stat() syscall; 32-bit libc uses the kernel's 'struct stat64'
> + and accesses it via the stat64() syscall. All the various
> + APIs offered by libc use the kernel shape for their struct stat
> + structure; the only difference is that 32-bit programs not
> + using __USE_FILE_OFFSET64 only see the low 32 bits of some
> + of the fields (specifically st_ino, st_size, and st_blocks). */
As I understand it, this strategy means that the glibc implementations of
the 32-bit APIs that fill in a 32-bit "struct stat" - that is, the
structure where some bits are hidden in padding - need to check that the
kernel has filled those bits with zeros and return an EOVERFLOW error if
not, so that users of the 32-bit interfaces do not get unreliable results.
I don't see any sign of that error handling in this patch.
The same applies to the statfs structure, and to any functions returning
off_t directly (which includes at least lseek).
> diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/Versions b/sysdeps/unix/sysv/linux/generic/wordsize-32/Versions
> new file mode 100644
> index 0000000..0ba05f9
> --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/Versions
> @@ -0,0 +1,6 @@
> +libc {
> + GLIBC_2.11 {
> + # Should probably be published in sysdeps/unix/sysv/linux/Versions.
> + fallocate64;
> + }
> +}
GLIBC_2.11 certainly won't be right for any new port using the generic
syscall ABI since no such port existed in glibc 2.11. The correct version
for each architecture would really be the value in that architecture's
shlib-versions file, making the setting here matter less as long as each
architecture has an appropriate shlib-versions, but GLIBC_2.15, as the
version in which generic syscall ABI support is added, is probably the
best version to put in this file.
--
Joseph S. Myers
joseph@codesourcery.com