[parisc-linux] glibc 2.2.3 make check status

[parisc-linux] glibc 2.2.3 make check status

[Matthew Wilcox]

I'm not sure people actually ran make check against glibc 2.2.1, so I don't
know how this compares.  Maybe 2.2.3 just has more tests than 2.2.1 did...

I'd love some help on this.  Really.  check the merge_GLIBC_CVS_20010424
branch out of CVS, configure it, make, then make check, and you'll start
hitting failures.  I've indicated the ones I've investigated.

 * all the tests in math/ fail.  pb knows what these problems are.

 * stdlib/strtold fails.  This is due to our long double being 64 bit and
   glibc thinks its 128 bit.  Bug #119

 * all the tests in dlfcn/ fail.  I haven't investigated these.

 * grp/testgrp fails.  This is a generic glibc 2.2.3 problem, the fix
   is available from upstream.

 * posix/testchmod fails.  This is due to a kernel bug in strncpy_from_user.
   Bug #118

 * posix/globtest fails.  Haven't investigated.

 * io/test-utime fails.  Looks like a stat problem.

 * misc/tst-efgcvt fails.  (Maybe another long double problem?)

 * gmon/tst-sprofil fails.  Looks like it needs to be ported to Linux/hppa.

 * linuxthreads/ and rt/ all hang.  I'll look at this.

 * elf/resolvfail and elf/constload1 fail.  Not investigated.  Probably other
   tests in elf/ also fail.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] glibc 2.2.3 make check status

[Matthieu Delahaye]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

Hi willy

Matthew Wilcox wrote:
> 
> I'm not sure people actually ran make check against glibc 2.2.1, so I don't
> know how this compares.  Maybe 2.2.3 just has more tests than 2.2.1 did...
> 
> I'd love some help on this.  Really.  check the merge_GLIBC_CVS_20010424
> branch out of CVS, configure it, make, then make check, and you'll start
> hitting failures.  I've indicated the ones I've investigated.

>  * posix/testchmod fails.  This is due to a kernel bug in strncpy_from_user.
>    Bug #118

The patch given above is supposed to correct this bug. It deals with the
fact that r24 counter is not "up to date" when the loop is stoped due to
a 0 byte's copy. 

I didn't find your merge_GLIBC_CVS_20010424 file. If you could point me
where
it is, I could perhaps try to help you as you request. More over, as you
might infer
I wasn't able to check the patch with the make check of the merge. The
only thing I know
is that my kernel still work with this patch , which is not a proof.

Regards,
Matthieu
-- 
Matthieu Delahaye
ESIEE Team
http://mkhppa1.esiee.fr/

[-- Attachment #2: strncopy_from_user.diff --]
[-- Type: text/plain, Size: 894 bytes --]

diff -Nru linux.old/arch/parisc/lib/lusercopy.S linux.new/arch/parisc/lib/lusercopy.S
--- linux.old/arch/parisc/lib/lusercopy.S	Sat May  5 16:43:40 2001
+++ linux.new/arch/parisc/lib/lusercopy.S	Sat May  5 16:44:00 2001
@@ -144,7 +144,7 @@
 	 *
 	 * Returns -EFAULT if exception before terminator,
 	 *         N if the entire buffer filled,
-	 *         otherwise strlen + 1 (i.e. includes zero byte)
+	 *         otherwise strlen (i.e. excludes zero byte)
 	 */
 
 	.export lstrncpy_from_user,code
@@ -153,7 +153,7 @@
 	.callinfo NO_CALLS
 	.entry
 	comib,=     0,%r24,$lsfu_done
-	copy        %r26,%r23
+	copy        %r24,%r23
 	get_sr
 1:      ldbs,ma     1(%sr1,%r25),%r1
 $lsfu_loop:
@@ -162,7 +162,7 @@
 	addib,<>,n  -1,%r24,$lsfu_loop
 2:      ldbs,ma     1(%sr1,%r25),%r1
 $lsfu_done:
-	sub         %r26,%r23,%r28
+	sub         %r23,%r24,%r28
 $lsfu_exit:
 	bv          %r0(%r2)
 	nop

Re: [parisc-linux] glibc 2.2.3 make check status

[Matthew Wilcox]

On Sat, May 05, 2001 at 05:12:39PM +0200, Matthieu Delahaye wrote:
> The patch given above is supposed to correct this bug. It deals with the
> fact that r24 counter is not "up to date" when the loop is stoped due to
> a 0 byte's copy. 

It does indeed, I shall check this in now.  Thank you for your help!
Would you like to close this bug?

> I didn't find your merge_GLIBC_CVS_20010424 file. If you could point me
> where
> it is, I could perhaps try to help you as you request. More over, as you
> might infer
> I wasn't able to check the patch with the make check of the merge. The
> only thing I know
> is that my kernel still work with this patch , which is not a proof.

cvs co -r merge_GLIBC_CVS_20010424 glibc

gets you the glibc I'm working on.  i could provide a patch against
upstream glibc 2.2.3 if there's interest?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] glibc 2.2.3 make check status

[Matthew Wilcox]

On Sat, May 05, 2001 at 03:34:57AM +0100, Matthew Wilcox wrote:
>  * io/test-utime fails.  Looks like a stat problem.

That's rather interesting.  It fails for me over NFS, but not on ramfs.
I'm going to log this as a kernel bug to remind me to report it upstream
if it can be reproduced on a later kernel revision.  This is something
people could do on a non-pa machine.

Re: [parisc-linux] glibc 2.2.3 make check status

[Paul Bame]

> 
> I'm not sure people actually ran make check against glibc 2.2.1, so I don't
> know how this compares.  Maybe 2.2.3 just has more tests than 2.2.1 did...

make check for 2.2.1 with the large file changes should only have failed
some of the fp tests.

>  * all the tests in math/ fail.  pb knows what these problems are.

If all the tests fail that's a problem. In 2.2.1 the fp  tests passed except
the ones where glibc computed something like trig functions, and those tests
were off in their least-significant bits.

Re: [parisc-linux] glibc 2.2.3 make check status

[Matthew Wilcox]

On Tue, May 08, 2001 at 07:48:05AM -0600, Paul Bame wrote:
> make check for 2.2.1 with the large file changes should only have failed
> some of the fp tests.

Damn.  Then people need to fix these new failures.  I'm working on the
linuxthreads/* and rt/* tests.

> If all the tests fail that's a problem. In 2.2.1 the fp  tests passed except
> the ones where glibc computed something like trig functions, and those tests
> were off in their least-significant bits.

not _all_ the math/* tests fail, I was exaggerating (it just felt
like it!)  there's 4-5 which fail... want to check them out, be sure we
aren't worse than glibc 2.2.1?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] glibc 2.2.3 make check status

[Matthew Wilcox]

An updated version of the list.  There's plenty of opportunity for people
to help with this.

Floating-point
--------------

 * Some of the math/ tests fail.  pb is looking into these.
 * stdlib/strtold fails.  This is due to our long double being 64 bit and
   glibc thinks its 128 bit.  Bug #119
 * misc/tst-efgcvt fails.  (Maybe another long double problem?)

Threads
-------

 * linuxthreads/ex10, ex15 & ex17 fail.  I'm working on these.
 * rt/tst-aio4 fails.  I'm working on this one too.

Dynamic Loading
---------------

 * all the tests in dlfcn/ fail.  I haven't investigated these.
 * elf/resolvfail and elf/constload1 fail.  Not investigated.  Probably other
   tests in elf/ also fail.

Misc
----

 * grp/testgrp fails.  This is a generic glibc 2.2.3 problem, the fix
   is available from upstream.
 * posix/globtest fails.  Haven't investigated.
 * gmon/tst-sprofil fails.  Looks like it needs to be ported to Linux/hppa.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] glibc 2.2.3 make check status

[Matthew Wilcox]

The list is getting shorter, and I believe we don't have any regressions
versus glibc 2.2.1 at this point.  Don't install the glibc 2.2.3 we have
in CVS, by the way.  It is missing necessary patches which are errata to
glibc 2.2.3.  These patches are not installed in our CVS tree to reduce
the amount of work when generating a new diff for the debian package.

I'd really appreciate some help with either of the problems in the
Misc section.

Floating-point
--------------

 * Some of the math/ tests fail in the same way they did with glibc-2.2.1.
 * stdlib/strtold fails.  This is due to our long double being 64 bit and
   glibc thinks its 128 bit.  Bug #119
 * misc/tst-efgcvt fails.  (Maybe another long double problem?)

Threads
-------

 * linuxthreads/ex15 fails sometimes.  I'm working on it.  (probable
 kernel bug)

Dynamic Loading
---------------

 * dlfcn/default fails.  Not sure whether the test is making an
   unwarranted assumption here or whether we have a bug.
 * The following tests in the elf/ directory fail:
	resolvfail constload1 vismain neededtest neededtest2
	neededtest3 neededtest4 lateglobal
   Not investigated.  Probably most of these are the same bug.

Misc
----

 * posix/globtest fails.  Haven't investigated.
 * gmon/tst-sprofil fails.  Looks like it needs to be ported to Linux/hppa.

-- 
Revolutions do not require corporate support.