[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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).

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: