glibc 2.3.1 - It's alive! - patches

PA,

These patches apply and build glibc 2.3.1, but we have interesting testsuite failures :}

In particular ex10 in the linuxthreads testsuite deadlocks and has to be killed by hand to continue testing.

We also fail a number of "needed" tests in the elf section. These tests cover the loading of DSO's with dlopen. Wether these are binutils bugs is yet to be seen.

Lastly, I think that the fp* tests suffer from the printf bug?

Pathes at:
http://www.baldric.uwo.ca/~carlos/upstream-patches.tar.gz

I don't think we are ready to push this into unstable until we iron out a few more of these bugs :(

c.

I am fairly certain that this is fixed in gcc 3.2/3.3. Could you do a build with the mainline gcc cvs? I am interested in feedback. as I am trying to squash as many bugs as possible in 3.3 while it's still open for general bug fixing.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

carlos@firin:/mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3$ hppa-linux-gcc-3.3 -v
Reading specs from /mnt/flaire/palinux/bin/../lib/gcc-lib/hppa-linux/3.3/specs
Configured with: ../gcc/configure --target=hppa-linux --build=hppa-linux --host=hppa-linux
--prefix=/mnt/flaire/palinux/ --enable-languages=c
Thread model: posix
gcc version 3.3 20021110 (experimental)

carlos@firin:/mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3$ ld -v
GNU ld version 2.13.90.0.10 20021010 Debian GNU/Linux

Latest CVS of glibc.2.3.1 with HPPA patches applied.

make[2]: Entering directory `/mnt/flaire/src/glibc-upstream-cvs/libc/glibc-2.3.1/linuxthreads' hppa-linux-gcc-3.3 ../linuxthreads/sysdeps/unix/sysv/linux/hppa/pt-initfini.c -c -std=gnu99 -O2
-Wall -Winline -Wstrict-prototypes -Wwrite-strings -g -g0 -fPIC -fno-inline-functions
-I../include -I. -I/mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3/linuxthreads -I.. -I../libio -I/mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3 -I../sysdeps/hppa/elf -I../linuxthreads/sysdeps/unix/sysv/linux/hppa -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/hppa -I../sysdeps/unix/sysv/linux/hppa -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/hppa/hppa1.1 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/ldbl-128 -I../sysdeps/hppa/fpu -I../sysdeps/hppa -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I
/lib/modules/2.4.19-pa22/build/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -S
-g0 -fPIC -fno-inline-functions -finhibit-size-directive \
-fno-exceptions -o
/mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3/linuxthreads/pt-initfini.s ../linuxthreads/sysdeps/unix/sysv/linux/hppa/pt-initfini.c:44:10: missing terminating " character ../linuxthreads/sysdeps/unix/sysv/linux/hppa/pt-initfini.c:46:10: #include expects "FILENAME" or <FILENAME>../linuxthreads/sysdeps/unix/sysv/linux/hppa/pt-initfini.c:51: error: request for member `section' in something not a structure or union ../linuxthreads/sysdeps/unix/sysv/linux/hppa/pt-initfini.c:52: error: parse error before numeric constant
../linuxthreads/sysdeps/unix/sysv/linux/hppa/pt-initfini.c:54: error: syntax error at '@' token ../linuxthreads/sysdeps/unix/sysv/linux/hppa/pt-initfini.c:75: error: stray '\' in program ../linuxthreads/sysdeps/unix/sysv/linux/hppa/pt-initfini.c:75:34: missing terminating " character ../linuxthreads/sysdeps/unix/sysv/linux/hppa/pt-initfini.c:86: error: syntax error at '@' token ../linuxthreads/sysdeps/unix/sysv/linux/hppa/pt-initfini.c:102: error: stray '\' in program ../linuxthreads/sysdeps/unix/sysv/linux/hppa/pt-initfini.c:102:34: missing terminating " character ../linuxthreads/sysdeps/unix/sysv/linux/hppa/pt-initfini.c:110:1: missing terminating " character make[2]: *** [/mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3/linuxthreads/pt-initfini.s] Error 1 make[2]: Leaving directory `/mnt/flaire/src/glibc-upstream-cvs/libc/glibc-2.3.1/linuxthreads' make[1]: *** [linuxthreads/others] Error 2
make[1]: Leaving directory `/mnt/flaire/src/glibc-upstream-cvs/libc/glibc-2.3.1'
make: *** [all] Error 2

Looks like we need some __asm format fixes?

c.

These are the changes that I had for glibc-2.2.5-14 to build with gcc-3.3. The string literal change makes the asms ugly but I think we have to live with it. I don't know the ins and outs of why the change was necessary but I know the cpp people will not change back.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

--- ./sysdeps/hppa/elf/initfini.c.orig	2001-07-09 17:56:22.000000000 -0700
+++ ./sysdeps/hppa/elf/initfini.c	2002-09-11 12:58:18.000000000 -0700
@@ -39,84 +39,84 @@
    making the comparison and indirect call is quite expensive (see the
    comment in sysdeps/generic/initfini.c). */
 
-__asm__ ("
-
-#include \"defs.h\"
-
-/*@HEADER_ENDS*/
-
-/*@_init_PROLOG_BEGINS*/
-	.section .init
-	.align 4
-	.globl _init
-	.type _init,@function
-_init:
-	stw	%rp,-20(%sp)
-	stwm	%r4,64(%sp)
-	stw	%r19,-32(%sp)
-	bl	__gmon_start__,%rp
-	copy	%r19,%r4	/* delay slot */
-	copy	%r4,%r19
-/*@_init_PROLOG_ENDS*/
-
-/*@_init_EPILOG_BEGINS*/
-        .text
-        .align 4
-        .weak   __gmon_start__
-        .type    __gmon_start__,@function
-__gmon_start__:
-	.proc
-	.callinfo
-	.entry
-        bv,n %r0(%r2)
-	.exit
-	.procend
-
-/* Here is the tail end of _init.  We put __gmon_start before this so
-   that the assembler creates the .PARISC.unwind section for us, ie.
-   with the right attributes.  */
-	.section .init
-	ldw	-84(%sp),%rp
-	copy	%r4,%r19
-	bv	%r0(%rp)
-_end_init:
-	ldwm	-64(%sp),%r4
-
-/* Our very own unwind info, because the assembler can't handle
-   functions split into two or more pieces.  */
-	.section .PARISC.unwind
-	.extern _init
-	.word	_init, _end_init
-	.byte	0x08, 0x01, 0x00, 0x08, 0x00, 0x00, 0x00, 0x08
-
-/*@_init_EPILOG_ENDS*/
-
-/*@_fini_PROLOG_BEGINS*/
-	.section .fini
-	.align 4
-	.globl _fini
-	.type _fini,@function
-_fini:
-	stw	%rp,-20(%sp)
-	stwm	%r4,64(%sp)
-	stw	%r19,-32(%sp)
-	copy	%r19,%r4
-/*@_fini_PROLOG_ENDS*/
-
-/*@_fini_EPILOG_BEGINS*/
-	.section .fini
-	ldw	-84(%sp),%rp
-	copy	%r4,%r19
-	bv	%r0(%rp)
-_end_fini:
-	ldwm	-64(%sp),%r4
-
-	.section .PARISC.unwind
-	.extern _fini
-	.word	_fini, _end_fini
-	.byte	0x08, 0x01, 0x00, 0x08, 0x00, 0x00, 0x00, 0x08
-
-/*@_fini_EPILOG_ENDS*/
-
-/*@TRAILER_BEGINS*/
+__asm__ ("\n\
+\n\
+#include \"defs.h\"\n\
+\n\
+/*@HEADER_ENDS*/\n\
+\n\
+/*@_init_PROLOG_BEGINS*/\n\
+	.section .init\n\
+	.align 4\n\
+	.globl _init\n\
+	.type _init,@function\n\
+_init:\n\
+	stw	%rp,-20(%sp)\n\
+	stwm	%r4,64(%sp)\n\
+	stw	%r19,-32(%sp)\n\
+	bl	__gmon_start__,%rp\n\
+	copy	%r19,%r4	/* delay slot */\n\
+	copy	%r4,%r19\n\
+/*@_init_PROLOG_ENDS*/\n\
+\n\
+/*@_init_EPILOG_BEGINS*/\n\
+        .text\n\
+        .align 4\n\
+        .weak   __gmon_start__\n\
+        .type    __gmon_start__,@function\n\
+__gmon_start__:\n\
+	.proc\n\
+	.callinfo\n\
+	.entry\n\
+        bv,n %r0(%r2)\n\
+	.exit\n\
+	.procend\n\
+\n\
+/* Here is the tail end of _init.  We put __gmon_start before this so\n\
+   that the assembler creates the .PARISC.unwind section for us, ie.\n\
+   with the right attributes.  */\n\
+	.section .init\n\
+	ldw	-84(%sp),%rp\n\
+	copy	%r4,%r19\n\
+	bv	%r0(%rp)\n\
+_end_init:\n\
+	ldwm	-64(%sp),%r4\n\
+\n\
+/* Our very own unwind info, because the assembler can't handle\n\
+   functions split into two or more pieces.  */\n\
+	.section .PARISC.unwind\n\
+	.extern _init\n\
+	.word	_init, _end_init\n\
+	.byte	0x08, 0x01, 0x00, 0x08, 0x00, 0x00, 0x00, 0x08\n\
+\n\
+/*@_init_EPILOG_ENDS*/\n\
+\n\
+/*@_fini_PROLOG_BEGINS*/\n\
+	.section .fini\n\
+	.align 4\n\
+	.globl _fini\n\
+	.type _fini,@function\n\
+_fini:\n\
+	stw	%rp,-20(%sp)\n\
+	stwm	%r4,64(%sp)\n\
+	stw	%r19,-32(%sp)\n\
+	copy	%r19,%r4\n\
+/*@_fini_PROLOG_ENDS*/\n\
+\n\
+/*@_fini_EPILOG_BEGINS*/\n\
+	.section .fini\n\
+	ldw	-84(%sp),%rp\n\
+	copy	%r4,%r19\n\
+	bv	%r0(%rp)\n\
+_end_fini:\n\
+	ldwm	-64(%sp),%r4\n\
+\n\
+	.section .PARISC.unwind\n\
+	.extern _fini\n\
+	.word	_fini, _end_fini\n\
+	.byte	0x08, 0x01, 0x00, 0x08, 0x00, 0x00, 0x00, 0x08\n\
+\n\
+/*@_fini_EPILOG_ENDS*/\n\
+\n\
+/*@TRAILER_BEGINS*/\n\
 ");
--- ./linuxthreads/internals.h.orig	2002-09-11 12:16:03.000000000 -0700
+++ ./linuxthreads/internals.h	2002-09-13 11:09:35.000000000 -0700
@@ -555,11 +555,11 @@
 /* Prototypes for compatibility functions.  */
 extern int __pthread_attr_init_2_1 (pthread_attr_t *__attr);
 extern int __pthread_attr_init_2_0 (pthread_attr_t *__attr);
-extern int __pthread_create_2_1 (pthread_t *__restrict __thread,
+extern int __pthread_create_2_1 (pthread_t *__restrict __thr,
 				 const pthread_attr_t *__attr,
 				 void *(*__start_routine) (void *),
 				 void *__restrict __arg);
-extern int __pthread_create_2_0 (pthread_t *__restrict thread,
+extern int __pthread_create_2_0 (pthread_t *__restrict __thr,
 				 const pthread_attr_t *__attr,
 				 void *(*__start_routine) (void *),
 				 void *__restrict arg);
--- ./linuxthreads/sysdeps/pthread/pthread.h.orig	2001-03-20 08:44:41.000000000 -0800
+++ ./linuxthreads/sysdeps/pthread/pthread.h	2002-09-11 12:38:24.000000000 -0700
@@ -160,7 +160,7 @@
 /* Create a thread with given attributes ATTR (or default attributes
    if ATTR is NULL), and call function START_ROUTINE with given
    arguments ARG.  */
-extern int pthread_create (pthread_t *__restrict __thread,
+extern int pthread_create (pthread_t *__restrict __thr,
 			   __const pthread_attr_t *__restrict __attr,
 			   void *(*__start_routine) (void *),
 			   void *__restrict __arg) __THROW;
@@ -588,7 +588,7 @@
 extern int pthread_setcanceltype (int __type, int *__oldtype) __THROW;
 
 /* Cancel THREAD immediately or at the next possibility.  */
-extern int pthread_cancel (pthread_t __thread) __THROW;
+extern int pthread_cancel (pthread_t __thr) __THROW;
 
 /* Test for pending cancellation for the current thread and terminate
    the thread as per pthread_exit(PTHREAD_CANCELED) if it has been
--- ./linuxthreads/sysdeps/unix/sysv/linux/bits/sigthread.h.orig	2000-09-11 10:32:02.000000000 -0700
+++ ./linuxthreads/sysdeps/unix/sysv/linux/bits/sigthread.h	2002-09-11 12:43:37.000000000 -0700
@@ -33,6 +33,6 @@
 			    __sigset_t *__restrict __oldmask)__THROW;
 
 /* Send signal SIGNO to the given thread. */
-extern int pthread_kill (pthread_t __thread, int __signo) __THROW;
+extern int pthread_kill (pthread_t __thr, int __signo) __THROW;
 
 #endif	/* bits/sigthread.h */

All of Uli's fixes have been the ugly way, though I'll change pt-initfini the nice and pretty way and hope they take the patch :)

c.

Either way is pretty if you space it nicely...
I think the following patch is correct, it's currently building...

c.

diff -urN glibc-2.3.1.orig/linuxthreads/sysdeps/unix/sysv/linux/hppa/pt-initfini.c glibc-2.3.1/linuxthreads/sysdeps/unix/sysv/linux/hppa/pt-initfini.c
@@ -41,70 +41,70 @@
    and epilogues.  Therefore we write these in assembly to make sure
    they do the right thing.  */
 
-__asm__ ("
-
-#include \"defs.h\"
-
-/*@HEADER_ENDS*/
-
-/*@_init_PROLOG_BEGINS*/
-	.section .init
-	.align 4
-	.globl _init
-	.type _init,@function
-_init:
-	stw	%rp,-20(%sp)
-	stwm	%r4,64(%sp)
-	stw	%r19,-32(%sp)
-	bl	__pthread_initialize_minimal,%rp
-	copy	%r19,%r4	/* delay slot */
-	copy	%r4,%r19
-/*@_init_PROLOG_ENDS*/
-
-/*@_init_EPILOG_BEGINS*/
-/* Here is the tail end of _init.  */
-	.section .init
-	ldw	-84(%sp),%rp
-	copy	%r4,%r19
-	bv	%r0(%rp)
-_end_init:
-	ldwm	-64(%sp),%r4
-
-/* Our very own unwind info, because the assembler can't handle
-   functions split into two or more pieces.  */
-	.section .PARISC.unwind,\"a\",@progbits
-	.extern _init
-	.word	_init, _end_init
-	.byte	0x08, 0x01, 0x00, 0x08, 0x00, 0x00, 0x00, 0x08
-
-/*@_init_EPILOG_ENDS*/
-
-/*@_fini_PROLOG_BEGINS*/
-	.section .fini
-	.align 4
-	.globl _fini
-	.type _fini,@function
-_fini:
-	stw	%rp,-20(%sp)
-	stwm	%r4,64(%sp)
-	stw	%r19,-32(%sp)
-	copy	%r19,%r4
-/*@_fini_PROLOG_ENDS*/
-
-/*@_fini_EPILOG_BEGINS*/
-	.section .fini
-	ldw	-84(%sp),%rp
-	copy	%r4,%r19
-	bv	%r0(%rp)
-_end_fini:
-	ldwm	-64(%sp),%r4
-
-	.section .PARISC.unwind,\"a\",@progbits
-	.extern _fini
-	.word	_fini, _end_fini
-	.byte	0x08, 0x01, 0x00, 0x08, 0x00, 0x00, 0x00, 0x08
-
-/*@_fini_EPILOG_ENDS*/
-
-/*@TRAILER_BEGINS*/
+__asm__ ("								\n\
+									\n\
+#include \"defs.h\"							\n\
+									\n\
+/*@HEADER_ENDS*/							\n\
+									\n\
+/*@_init_PROLOG_BEGINS*/						\n\
+	.section .init							\n\
+	.align 4							\n\
+	.globl _init							\n\
+	.type _init,@function						\n\
+_init:									\n\
+	stw	%rp,-20(%sp)						\n\
+	stwm	%r4,64(%sp)						\n\
+	stw	%r19,-32(%sp)						\n\
+	bl	__pthread_initialize_minimal,%rp			\n\
+	copy	%r19,%r4	/* delay slot */			\n\
+	copy	%r4,%r19						\n\
+/*@_init_PROLOG_ENDS*/							\n\
+									\n\
+/*@_init_EPILOG_BEGINS*/						\n\
+/* Here is the tail end of _init.  */					\n\
+	.section .init							\n\
+	ldw	-84(%sp),%rp						\n\
+	copy	%r4,%r19						\n\
+	bv	%r0(%rp)						\n\
+_end_init:								\n\
+	ldwm	-64(%sp),%r4						\n\
+									\n\
+/* Our very own unwind info, because the assembler can't handle		\n\
+   functions split into two or more pieces.  */				\n\
+	.section .PARISC.unwind,\"a\",@progbits				\n\
+	.extern _init							\n\
+	.word	_init, _end_init					\n\
+	.byte	0x08, 0x01, 0x00, 0x08, 0x00, 0x00, 0x00, 0x08		\n\
+									\n\
+/*@_init_EPILOG_ENDS*/							\n\
+									\n\
+/*@_fini_PROLOG_BEGINS*/						\n\
+	.section .fini							\n\
+	.align 4							\n\
+	.globl _fini							\n\
+	.type _fini,@function						\n\
+_fini:									\n\
+	stw	%rp,-20(%sp)						\n\
+	stwm	%r4,64(%sp)						\n\
+	stw	%r19,-32(%sp)						\n\
+	copy	%r19,%r4						\n\
+/*@_fini_PROLOG_ENDS*/							\n\
+									\n\
+/*@_fini_EPILOG_BEGINS*/						\n\
+	.section .fini							\n\
+	ldw	-84(%sp),%rp						\n\
+	copy	%r4,%r19						\n\
+	bv	%r0(%rp)						\n\
+_end_fini:								\n\
+	ldwm	-64(%sp),%r4						\n\
+									\n\
+	.section .PARISC.unwind,\"a\",@progbits				\n\
+	.extern _fini							\n\
+	.word	_fini, _end_fini					\n\
+	.byte	0x08, 0x01, 0x00, 0x08, 0x00, 0x00, 0x00, 0x08		\n\
+									\n\
+/*@_fini_EPILOG_ENDS*/							\n\
+									\n\
+/*@TRAILER_BEGINS*/							\n\
 ");

With gcc-3.3 experimental (cvs pull as of yesterday):

make[2]: *** [/math/test-fenv.out] Error 136 make[2]: *** [/math/test-float.out] Error 1 make[2]: *** [/math/test-double.out] Error 1 make[2]: *** [/math/test-ifloat.out] Error 1 make[1]: *** [math/tests] Error 2

= Same as before, I'm going to regen these right now.

make[2]: *** [/stdlib/bug-strtod.out] Error 1 make[1]: *** [stdlib/tests] Error 2
make[2]: *** [/libio/tst-mmap-eofsync.out] Error 1 make[2]: *** [/libio/tst-mmap-fflushsync.out] Error 1 make[1]: *** [libio/tests] Error 2
make[2]: *** [/dlfcn/default.out] Error 1 make[2]: *** [/dlfcn/tststatic.out] Error 139 make[1]: *** [dlfcn/tests] Error 2
make[2]: [/posix/annexc.out] Error 1 (ignored) make[2]: *** [/elf/tst-array1.out] Error 1 make[2]: *** [/elf/tst-array2.out] Error 1 make[2]: *** [/elf/tst-array3.out] Error 1

= These three are new!
= They seem to be a common failure on x86

make[2]: *** [/elf/vismain.out] Error 1 make[2]: *** [/elf/neededtest.out] Error 14 make[2]: *** [/elf/neededtest2.out] Error 14 make[2]: *** [/elf/neededtest3.out] Error 17 make[2]: *** [/elf/neededtest4.out] Error 2 make[2]: *** [/elf/circleload1.out] Error 9 make[1]: *** [elf/tests] Error 2
make: *** [check] Error 2

c.

I am not surprised about these. There definitely problems with the visibility of symbols based on the binutils testsuite. These didn't show up before because the visibility tests didn't run on the pa.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

The fix is non-obvious to me. I have no idea where to begin here. Any hints? :)

c.

It isn't obvious to me either other than the problem is probably in elf32-hppa.c. I would look at the testsuite results for ld, pick a simple test that fails and try to figure out what is going wrong.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

here's a trivial test case in case anyone wants to track this down :-)

======= undef.s ==========
.protected protected
.hidden hidden
.internal internal
==========================

assemble with 'as -o undef.o undef.s' and run 'readelf -s undef.o'

on pa, you get:
Symbol table '.symtab' contains 4 entries:

   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 SECTION LOCAL  DEFAULT    1
     2: 00000000     0 SECTION LOCAL  DEFAULT    2
     3: 00000000     0 SECTION LOCAL  DEFAULT    3

on ia32/ia64, i get this more reasonable output:

Symbol table '.symtab' contains 7 entries:

   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 SECTION LOCAL  DEFAULT    1
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    2
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    3
     4: 0000000000000000     0 NOTYPE  GLOBAL PROTECTED  UND protected
     5: 0000000000000000     0 NOTYPE  GLOBAL HIDDEN  UND hidden
     6: 0000000000000000     0 NOTYPE  GLOBAL INTERNAL  UND internal

randolph

Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Please post to binutils. I'm tied up for a bit trying to track a ld bug on hppa64. I've managed to break gcc when using gnu ld :( Sometimes HP stuff works better.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Hrm....

test-double.out says:

GCONV_PATH=/mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3/iconvdata LC_ALL=C /mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3/elf/ld.so.1 --library-path /mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3:/mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3/math:/mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3/elf:/mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3/dlfcn:/mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3/nss:/mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3/nis:/mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3/rt:/mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3/resolv:/mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3/crypt:/mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3/linuxthreads /mnt/flaire/src/glibc-upstream-cvs/libc-build-3.3/math/test-double

testing double (without inline functions)
Failure: Real part of: cacos (inf + NaN i) == NaN + inf i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: cacos (-inf + NaN i) == NaN + inf i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: cacos (NaN + inf i) == NaN - inf i: Exception "Invalid operation" set
Failure: Real part of: cacos (NaN - inf i) == NaN + inf i: Exception "Invalid operation" set
Failure: Real part of: cacos (NaN + NaN i) == NaN + NaN i: Exception "Invalid operation" set
Failure: Real part of: ccosh (0.0 + NaN i) == NaN + 0.0 i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: ccosh (-0 + NaN i) == NaN + 0.0 i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: ccosh (inf + NaN i) == inf + NaN i: Exception "Invalid operation" set
Failure: Real part of: ccosh (-inf + NaN i) == inf + NaN i: Exception "Invalid operation" set
Failure: Real part of: cpow (NaN + NaN i, NaN + NaN i) == NaN + NaN i: Exception "Invalid operation" set
Failure: Real part of: csinh (0.0 + NaN i) == 0.0 + NaN i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: csinh (-0 + NaN i) == 0.0 + NaN i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: csinh (inf + NaN i) == inf + NaN i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: csinh (-inf + NaN i) == inf + NaN i plus sign of zero/inf not specified: Exception "Invalid operation" set

Test suite completed:
2518 test cases plus 2306 tests for exception flags executed. 14 errors occurred.

They look to be exception related?

c.

I doubt this is a gcc problem but it might be. Certain floating-point compare instructions can generate invalid operation exceptions. It's been awhile but I don't think we use these (see page 8-16 of PA 2.0 arch). An invalid operation exception will always occur with signaling nans.

You need to try to identify the insn that is causing the exception. This can be difficult in some cases because the exceptions are inexact.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Again, delayed traps can be "Invalid Operation" exceptions within these floating point tests. We may be seeing some of those issues. I really need to find a way to properly flush delayed exceptions.

c.

Look at fldw,fstw. Specifying register 0L forces the coprocessor to complete all previous floating-point insns.

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

We currently use the following as a delayed exception trap barrier:

libc/glibc-2.3.1/sysdeps/hppa/fpu/fraiseexcpt.c

...
__asm__ __volatile__ ("fmpy,dbl %1,%%fr0,%0\n\t"

			/* FIXME: is this a proper trap barrier? */
			"fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0"(d));

...

And from the comment it seems that DHD wasn't sure either :) I don't quite understand what is meant by specifying register 0L?

c.

You just have to do a floating-point load/store to/from register 0/0L using a doubleword/word instruction. See the arch manual and the comments about specify register 0 near the bottom of each instruction description. 0L is the left part of floating register 0. Doing this as a volatile asm should force completion of all previous floating-point instructions.

A store from register 0 (the floating point status register) is a safe barrier but you need to provide a location to store to.

I don't believe "fcpy,dbl %%fr0,%%fr0" provides the barrier that you want. The floating-point coprocessor is not required to execute instructions sequentially although they must appear sequential to software. The above insn is a nop and the coprocessor could throw it away early in the pipeline.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

That's what I was beggining to think.
I'll spill it onto the stack as Lamont suggested some time ago.

c.

Looking at feraiseexcept, I see that you only want to raise one exception at a time out of a specified set. Reading the status register will raise all outstanding exceptions. I think what needs to be done is something like the following:

__asm__ __volatile__ ("fmpy,dbl %1,%%fr0,%0\n\t"
"fcmp,dbl,!= %%fr0,%0\n\t"
"ftest\n\t"
"nop" : "=f" (d) : "0"(d));

Doing a compare and test of the result of the fmpy insn will ensure that any exceptions related to that operation are raised prior to the ftest insn being queued in floating-point coprocessor.

There is some information in pa.md on the floating-point units used with different processors. For example, the 7100LC has three floating-point
units: ALU, MUL, and DIV. The situation in the PA8000 is much more complicated because of its large reorder buffer (56 entries).

When an exception occurs, it sets the T bit and the coprocessor is armed to trap if the exception enable for the trap is 1. The trap is taken at the next floating point insn. However, because of the out of order execution of instructions and multiple floating-point units, care has to be taken in selecting the following insn. It has to have a dependency on the trap generating insn to ensure that it actually follows. Possibly, the ftest is unnecessary but it ensures that any traps related to the previous two insns are taken.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

After a night's sleep, I had a couple more thoughts on this.

1) You probably want to clear the T bit at the beginning of the routine. This will ensure that you get the correct exception when the first one is raised. The only way to do this without potentially causing a pending trap to trigger is with a double word store to floating-point register 0. You can't read register 0 before the write without potentially triggering a trap, so you need to know what the current state should be. See page 10-5 of the PA2 arch manual.

2) A fcpy insn should raise an exception if it depends on the result of a pending trapping insn (the current code doesn't). It would be best to not use register 0 or the source register for the destination register since in theory the processor would then know the operation is a nop. Then, the insn could be reordered or discarded. The fcpy insn is nice since it is non-arithmetic and doesn't cause an invalid operation exception when a NaN is copied. The fcmp insn isn't quite as nice since it will generate an invalid operation when one of the values is a signaling NaN, or if the low-order bit of the condition code is 1 and one of the values is an NaN.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

This isn't right. According to "Delayed Trapping" on p. 10-5 of the PA-RISC 2.0 book, an fcpy need not raise a pending exception, because it is not mentioned in the "delayed trap must occur" list.

Now, it's possible that it might (usually) work on the processor implementations you're interested in, but it's not architecturally guaranteed.

-- Jim
HP PA-RISC (and IPF) Processor Architect

What about "The current instruction is a load or store of the detination register of a pending trapping instruction or an operation which depends on a pending trapping instruction"?

I think the latter part of the sentence would apply to a fcpy of the destination register of a pending trapping instruction.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Dave:

destination

depends

I thought that might be the item you were thinking of. Sometimes, in our effort to be as concise as possible, we went too far in the PA-RISC book.

The correct interpretation of that sentence is:

The current instruction is a load or store of the destination register of a pending trapping instruction,

or

the current instruction is a load or store of the destination register of an operation which depends on a pending trapping instruction.

In other words, it must be a load or store of a destination register, either of the pending trapping instruction itself, or of any subsequent instruction which depends on that pending trapping instruction.

Hope this helps.

-- Jim

Ok.

Another issue that was somewhat vague was whether the state could be saved without triggering pending traps. Page 10-13 discusses special treatment of a double word store of register 0 and states that it cancels all pending traps. On the otherhand, item 3 in the hit list and the instruction description don't mention this treatment.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Dave:

saved

treatment

instruction

Yes, you can save state without "triggering pending traps", if what you mean by "triggering" is that you end up at the assist exception trap handler.

This is described in step 5 of the numbered list on p. 10-6, which describes what happens when a delayed trap occurs.

-- Jim

Thanks. I think it is now clear how to implement the function to raise a specific set of exceptions, one at a time.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

So really the fix is to spill into a third register or a memory location in order to:

1) Prevent reordering and subsequent discard of the insn
2) Trigger the trap since the result of the register is needed

Okie, lets see if I have this right:

1) Routine starts
2) Clear T by reading fr0 and writing back with T=0 = All other pending delayed exceptions are nulled
3) Setup an exception to occur based on requirements = insn writes to dX
4) Trap barrier

	= insn where dX is copied to dY (dX!=dY)

I liked the fcpy specifically for that reason. It doesn't itself cause a recursive triggering of more delayed exceptions, eventually filling the exception queue and delivering an exception anyway ;)

c.

That's the general idea. However, fcpy won't always trigger the trap as the T bit may not be set when it executes even if it depends on the exception generating instruction. You have to use a load or store to %0, or a load or store to %1, or a fcmp,ftest,nop sequence that depends on the exception generating instruction. You don't actually have to spill the result. For example, a "fldd 0(%%sp),%0" or "fldd 0(%%sp),%1" should raise the exception. The stack pointer should always be sufficiently aligned.

I would suggest saving the whole state. Reading fr0 with a double word store will automatically clear T. I believe that there is a function do to that. You might then clear the exception registers and set the status register to a state with the exception enables appropriately set. If you are paranoid, you could set the enable for just the exception that you want to raise at each step.

The state can be restored at the end. I am not quite sure what is required at this point. Should the function remove any or all pending exceptions?

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

It occurred to me these might be a gcc problem on PA1 machines. These machines don't have fneg and negation is currently implemented as the product with -1. This may cause invalid operation to be set if the value is a signaling NaN.

A better way to do the negation is to toggle the sign bit but this is inefficient as the value needs to be copied from a FPR to a GPR and back again.

A quick check would be to run the tests with "-mpa-risc-2-0" and see if this makes any difference.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Interesting. I shall add this to my list of checks todo once I get glibc 2.3.1 out the door. Everything is setup, I'm just running into some package integration problems (e.g. failing to restart certain services causes the dpkg -i to fail).

My todo includes:

- Follow our discussion on delayed exceptions and try a few implementations of trap barriers

- Examine if -1*NaN is causing failures in the fp glibc tests.

- Implement atomic_add, echange_and_add, and compare and swap, which are required in atomicity.h

- Make some progress implementing *context() calls in glibc (SAPDB needs them).

- Take a closer look at our setjump/longjmp impementation (there were some fears that it was mildly broken)

c.

I added an implementation of atomic_add and echange_and_add to libstdc++ recently. You can probably copy most of it for glibc, although the libstdc++ implementation is for c++. The main problem would be in initializing the 16 byte lock structure.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

We already have a 16-byte aligned lock structure in glibc for pthreads, and I plan to use the same construct in atomicity.h.

...

typedef struct {
       int lock;
} __attribute__((aligned (16))) __atomic_lock_t;

...
#define __LOCK_INIT = { 1 };
static __atomic_lock_t __hppa_lock = __LOCK_INIT;
...
Ref the above lock in my __asm statement and use ldcw and a loop to make sure the C function stays atomic for those threads (similar implementation to sparc and mips).

c.

You might consider whether a separate lock structure might be appropriate. Otherwise, it might be possible for a deadlock to occur.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Last I looked, we suffered from the fact that glibc thinks long double' is 96 bits, gcc thinks long double' is 64 bits and gcc-hpux thinks that `long double' is 128 bits. I've been whining about this for over a year and nothing's happened. I think it's fairly clear that not much uses long double, otherwise we'd've noticed more failure cases. So changing both gcc & glibc to a 128-bit long double is the Right Thing to do and we can just suck up this ABI breakage.

In case anyone's wondering, the architecture specifies 32-bit, 64-bit and 128-bit floating point registers as being available. My understanding is that no processor has actually implemented the 128-bit floating point ops (except maybe load and store) and they always trap to the FP emulation code (which we copied from HPUX).

Revolutions do not require corporate support.

Paul Bame was working on getting HP to release their long double library code. I haven't heard what the status is. If he gets the code, then it should be relatively straight forward to integrate into libgcc and use the same code as for hpux. Can glibc handle 128-bit long doubles as that's the size long doubles will be if we get the code?

There are two tests in the libstdc++-v3 suite that fail because of this. However, there can't be much in the way of real world code that actually uses long doubles.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

It looks we have the framework. The glibc tree has sysdeps/ieee754/ldbl-128 which looks to be used by hppa and sparc64. The code was last touched by Jakub Jelinek in 2002-09-09 (cleaning up some cruft). ldlb-128 does get parsed as one of the generic-dirs in Make-dist. For all intents and purposes we have soft-emulated support :)

c.

Then, I should look at what sparc64 is doing and maybe all we need to do is implement something similar. We may not need the HP stuff.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Nope, we need it. Sparc uses library calls like "_Q_add" for the basic operations on quad values.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

We need it or else we have to fall back on completely software emulated quad arithmetic. Though the framework for replacing all those function calls is available.

Note that GMP was included in the libc tree at one point, but recently it's rotted away and Roland was recently removing the last bits in 2002-09-20. I'm not sure what ever came of this? It looks like GMP 2.0 was pushed into the tree in '96 as a generic method for doing unlimited precision math?

I've only just realized how usefull having extremely descriptive Changelog's can be :)

c.

As Willy mentioned, no PA processors actually implement quad arithmetic at this time although it is part of the PA 2.0 architecture. So, we have to use software emulation and there is no point at this time in adding the quad arithmetic ops to pa.md definition. The simplest approach is to use the libcall interface already implemented for hpux (see pa/long_double.h).

While GMP is a useful package, it doesn't emulate IEEE 754 arithmetic. That's what we need here. There's a floating point emulator in gcc/real.c but I think the HP library would be superior.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Ah yes, correct, I had forgotten that it was never implemented in silica. So you suggest we not implement this in libc but rather in gcc, may I ask why?

I'm pretty sure that MPFR library in GMP can emulate IEEE 754 arithmetic, though I could be wrong.

c.

I don't have a strong opinion on this. Probably, the routines should be in libc. However, it's probably simple also to put them in libgcc which contains some arithmetic operations. Some work in gcc would be needed in any event to integrate the package.

I found the quad double package at the mpfr site. However, its double double differs from the IEEE quad precision representation. A double double is a representation using two IEEE doubles. This is fine as a separate library but not the IEEE implementation we are looking for.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

I've just seen recent binutils ditatrabe about how we have copies of math libraries floating between glibc, gcc and the kernel.

What do we gain from putting it in gcc?
- ?

What do we gain from putting it libc?
- More frequent package updates?
- IMO easier to debug?

Why are there math functions in libgcc in the first place? Historical reasons?

Okay.

c.

Well, for closed systems like hpux, it was necessary if the compiler needed the function. We are talking here about basic operations on floats and ints (see config/fp-bit.[ch] and libgcc2.c).

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)