Bug#665897: eglibc: [mips, mipsel] wrong RLIM_INFINITY for LFS
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
Reply to: