Source: eglibc Version: 2.13-27 (The MIPS porters may please set a severity on this.)
I’ve discovered this as a problem with the shells’ ulimit builtin (both mksh and GNU bash affected as they’re built with LFS, dash isn’t, and mksh-static uses dietlibc on both mips and mipsel which just ignores -D_FILE_OFFSET_BITS=64). Basically, RLIM_INFINITY on a bunch of platforms is, apparently historically, not all-bits-one but all-bits-one-SHR-1. This works fine for the non-LFS case but disagrees with the data the Linux kernel sends for the LFS case: tg@gabrielli:~$ dchroot sid Executing shell in chroot: /chroot/sid (sid)tg@gabrielli:~$ cat x.c #include <sys/types.h> #include <sys/time.h> #include <sys/resource.h> #include <err.h> #include <stdio.h> int main(void) { struct rlimit r; if (getrlimit(RLIMIT_DATA, &r)) err(1, "getrlimit"); printf("%016llX %016llX\n", (unsigned long long)r.rlim_cur, (unsigned long long)RLIM_INFINITY); return (0); } (sid)tg@gabrielli:~$ gcc x.c (sid)tg@gabrielli:~$ ./a.out 000000007FFFFFFF 000000007FFFFFFF (sid)tg@gabrielli:~$ gcc x.c -D_FILE_OFFSET_BITS=64 (sid)tg@gabrielli:~$ ./a.out FFFFFFFFFFFFFFFF 7FFFFFFFFFFFFFFF The documented ABI for this (via the linux-libc-dev package) is: /usr/include/mips-linux-gnu/asm/resource.h:# define RLIM_INFINITY 0x7fffffffUL /usr/include/asm-generic/resource.h:# define RLIM_INFINITY (~0UL) So the special-casing of Alpha, MIPS and SPARC apparently is wrong for the LFS case, and this is a bug in eglibc. At least this is what I think after this analysis ;-) Other info: (sid)tg@gabrielli:~$ uname -a Linux gabrielli 3.2.0-0.bpo.1-octeon #1 SMP Sun Feb 12 21:03:30 UTC 2012 mips64 GNU/Linux (sid)tg@eder:~$ uname -a Linux eder 2.6.39-3-loongson-2e #1 Sat Aug 20 16:36:12 UTC 2011 mips64 GNU/Linux These are the two affected systems I can reproduce things with (mips and mipsel, in this order). bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1203262022440.27...@herc.mirbsd.org