Bug#642112: [PATCH] timers for kFreeBSD

2012-03-26 Thread Robert Millan
El 26 de març de 2012 0:14, Robert Millan  ha escrit:
> 9.0/i386 kernel running i386 binary -> GOOD
> 10.0/i386 kernel running i386 binary -> GOOD

Sorry but my i386 tests were wrong, I did them while using unpatched
libc (sigh).  Here are some proper tests for i386 (same result using
kfreebsd 8.3, 9.0 and 10-current):

tst-timer: segfault
tst-timer2: bad
tst-timer3: good
tst-timer4: bad
tst-timer5: bad (not a regression, previously it was skipped)

-- 
Robert Millan



--
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/CAOfDtXPKTj7�8ezSqP8rKKk38kNMASTq7hJaQ9wtswf6=o...@mail.gmail.com



Bug#665897: eglibc: [mips, mipsel] wrong RLIM_INFINITY for LFS

2012-03-26 Thread Thorsten Glaser
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 
#include 
#include 
#include 
#include 
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
7FFF 7FFF
(sid)tg@gabrielli:~$ gcc x.c -D_FILE_OFFSET_BITS=64
(sid)tg@gabrielli:~$ ./a.out
 7FFF

The documented ABI for this (via the linux-libc-dev package) is:

/usr/include/mips-linux-gnu/asm/resource.h:# define RLIM_INFINITY   
0x7fffUL
/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