[parisc-linux] glibc 2.3.1 - It's alive! - patches

[parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

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.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

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

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Matthew Wilcox]

On Sun, Nov 10, 2002 at 08:05:17PM -0500, Carlos O'Donell wrote:
> Lastly, I think that the fp* tests suffer from the printf bug?

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.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

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

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

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

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.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

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

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

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

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

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

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

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.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

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

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

> 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?

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

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

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?

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

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

c.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

> > Lastly, I think that the fp* tests suffer from the printf bug?
> 
> 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.
> 

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.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

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

> > 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.
> 
> I'm pretty sure that MPFR library in GMP can emulate IEEE 754 arithmetic, 
> though I could be wrong.

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

> Looks like we need some __asm format fixes?

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                                  dave.anglin@nrc.ca
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 */

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

> 
> 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'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?

> > I'm pretty sure that MPFR library in GMP can emulate IEEE 754 arithmetic, 
> > though I could be wrong.
> 
> 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.
> 

Okay.

c.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

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

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Matthew Wilcox]

On Mon, Nov 11, 2002 at 12:36:25PM -0500, John David Anglin wrote:
> > Looks like we need some __asm format fixes?
> 
> 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.

> +	stw	%rp,-20(%sp)\n\
> +	stwm	%r4,64(%sp)\n\
> +	stw	%r19,-32(%sp)\n\

By and large we've preferred the following style which is less ugly, IMO:

"	stw	%rp,-20(%sp)\n"
"	stwm	%r4,64(%sp)\n"
"	stw	%r19,-32(%sp)\n"

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

On Mon, Nov 11, 2002 at 06:00:16PM +0000, Matthew Wilcox wrote:
> On Mon, Nov 11, 2002 at 12:36:25PM -0500, John David Anglin wrote:
> > > Looks like we need some __asm format fixes?
> > 
> > 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.
> 
> > +	stw	%rp,-20(%sp)\n\
> > +	stwm	%r4,64(%sp)\n\
> > +	stw	%r19,-32(%sp)\n\
> 
> By and large we've preferred the following style which is less ugly, IMO:
> 
> "	stw	%rp,-20(%sp)\n"
> "	stwm	%r4,64(%sp)\n"
> "	stw	%r19,-32(%sp)\n"
> 

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.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

> > 
> > > +	stw	%rp,-20(%sp)\n\
> > > +	stwm	%r4,64(%sp)\n\
> > > +	stw	%r19,-32(%sp)\n\
> > 
> > By and large we've preferred the following style which is less ugly, IMO:
> > 
> > "	stw	%rp,-20(%sp)\n"
> > "	stwm	%r4,64(%sp)\n"
> > "	stw	%r19,-32(%sp)\n"
> > 
> 
> 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 :)
> 

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
--- glibc-2.3.1.orig/linuxthreads/sysdeps/unix/sysv/linux/hppa/pt-initfini.c	2002-08-26 18:39:29.000000000 -0400
+++ glibc-2.3.1/linuxthreads/sysdeps/unix/sysv/linux/hppa/pt-initfini.c	2002-11-11 13:36:31.000000000 -0500
@@ -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\
 ");

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

> > Looks like we need some __asm format fixes?
> 
> 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.
> 

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.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

> 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

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

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

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.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

On Mon, Nov 11, 2002 at 03:57:37PM -0500, John David Anglin wrote:
> > 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
> 
> 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.
> 

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

c.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

> > 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.
> > 
> 
> The fix is non-obvious to me. I have no idea where to begin here.
> Any hints? :)

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

> 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?

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

> > 
> > Test suite completed:
> >   2518 test cases plus 2306 tests for exception flags executed.
> >   14 errors occurred.
> > 
> > They look to be exception related?
> 
> 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.
> 

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.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

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

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

-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

> > 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.
> 
> Look at fldw,fstw.  Specifying register 0L forces the coprocessor
> to complete all previous floating-point insns.
> 

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.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

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

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

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

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

c.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

> __asm__ __volatile__ ("fmpy,dbl %1,%%fr0,%0\n\t"
> 			/* FIXME: is this a proper trap barrier? */
> 			"fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0"(d));

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

[parisc-linux] simple testcase for binutils visibility problem

[Randolph Chung]

> > The fix is non-obvious to me. I have no idea where to begin here.
> > Any hints? :)
> 
> 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.

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/

Re: [parisc-linux] simple testcase for binutils visibility problem

[John David Anglin]

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

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

> > __asm__ __volatile__ ("fmpy,dbl %1,%%fr0,%0\n\t"
> > 			/* FIXME: is this a proper trap barrier? */
> > 			"fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0"(d));
> 
> Looking at fraiseexcept, 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:

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

RE: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Jim Hull]

John David Anglin wrote:

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

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

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

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

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

RE: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Jim Hull]

Dave:

> What about "The current instruction is a load or store of the
destination
> 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.

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

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

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

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

RE: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Jim Hull]

Dave:

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

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

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

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

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

On Tue, Nov 12, 2002 at 10:44:07AM -0500, John David Anglin wrote:
> > > __asm__ __volatile__ ("fmpy,dbl %1,%%fr0,%0\n\t"
> > > 			/* FIXME: is this a proper trap barrier? */
> > > 			"fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0"(d));

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

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

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)

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

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.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

> On Tue, Nov 12, 2002 at 10:44:07AM -0500, John David Anglin wrote:
> > > > __asm__ __volatile__ ("fmpy,dbl %1,%%fr0,%0\n\t"
> > > > 			/* FIXME: is this a proper trap barrier? */
> > > > 			"fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0"(d));
> 
> 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

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.

> 2) Clear T by reading fr0 and writing back with T=0
> 	= All other pending delayed exceptions are nulled

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.

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

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

> 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

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

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

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.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

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

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

> > - Implement atomic_add, echange_and_add, and compare and swap, which are
> >   required in atomicity.h
> 
> 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.
> 

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.

Re: [parisc-linux] glibc 2.3.1 - It's alive! - patches

[John David Anglin]

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

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)