Remaining Itanium exception, static linking patches

["Boehm, Hans" <hans_boehm at hp dot com>]

I already posted two messages about Itanium exception handling issues that
also affect C++ (http://gcc.gnu.org/ml/gcc-patches/2002-03/msg00806.html and
http://gcc.gnu.org/ml/gcc/2002-03/msg00683.html )  This is a list of the
remaining (short) ones I have been using to compile SPECjbb.  I think the
first two originally came from Andrew Haley.

The first one turns on dwarf2-exception-style signal handling for IA64.  The
file naming here is probably suboptimal, since IA64 uses unwind information
separate from the debugging information, and thus AFAICT, there is actually
no relation to dwarf2.  But other than that this one should be
uncontroversial.  I would like to check it in as is, into both the trunk and
branch.

	* configure.in, configure: enable dwarf2-exception-style signal
handling on IA64

 
Index: libjava/configure
===================================================================
RCS file: /cvs/gcc/gcc/libjava/configure,v
retrieving revision 1.126.2.4
diff -u -r1.126.2.4 configure
--- configure	2002/03/10 03:30:40	1.126.2.4
+++ configure	2002/03/14 16:44:18
@@ -6374,6 +6374,9 @@
 #    SYSDEP_SOURCES=sysdep/ia64.c
 #    test -d sysdep || mkdir sysdep
 #    ;;
+ ia64-*-linux*)
+    SIGNAL_HANDLER=include/dwarf2-signal.h
+    ;;
  powerpc-*-linux*)
     SIGNAL_HANDLER=include/dwarf2-signal.h
     ;;
Index: libjava/configure.in
===================================================================
RCS file: /cvs/gcc/gcc/libjava/configure.in,v
retrieving revision 1.114.2.3
diff -u -r1.114.2.3 configure.in
--- configure.in	2002/03/10 03:30:48	1.114.2.3
+++ configure.in	2002/03/14 16:44:18
@@ -841,6 +841,9 @@
 #    SYSDEP_SOURCES=sysdep/ia64.c
 #    test -d sysdep || mkdir sysdep
 #    ;;
+ ia64-*-linux*)
+    SIGNAL_HANDLER=include/dwarf2-signal.h
+    ;;
  powerpc-*-linux*)
     SIGNAL_HANDLER=include/dwarf2-signal.h
     ;;

The next one is the IA64-specific patch to dwarf2-signal.h.  I think the
MAKE_THROW_FRAME definition is necessary.  I'm not sure the change to
__libc_sigaction is necessary anymore.  Unless someone thinks it is, I would
like to test without it, and check in only the first part of the patch:

Index: libjava/include/dwarf2-signal.h
===================================================================
RCS file: /cvs/gcc/gcc/libjava/include/dwarf2-signal.h,v
retrieving revision 1.3
diff -u -r1.3 dwarf2-signal.h
--- dwarf2-signal.h	2001/05/29 17:50:50	1.3
+++ dwarf2-signal.h	2002/03/14 16:44:18
@@ -41,7 +41,22 @@
   _sc->sc_pc += 4;							\
 }									\
 while (0)
+
+#elif defined(__ia64__)
+
+#define MAKE_THROW_FRAME(_exception)					\
+do									\
+{									\
+  /* IA-64 either leaves PC pointing at a faulting instruction or the	\
+   following instruction, depending on the signal.  SEGV always does	\
+   the former, so we adjust the saved PC to point to the following	\
+   instruction; this is what the handler in libgcc expects.  */
\
+  struct sigcontext *_sc = (struct sigcontext *)_p;			\
+  _sc->sc_ip++;	 /* fprintf (stderr, "%p si:%p sc:%p\n",
_sc->sc_ip, si, _p); */						\
+}									\
+while (0)
 #else
+#error
 #define MAKE_THROW_FRAME(_exception)		\
 do						\
 {						\
@@ -50,6 +65,10 @@
 while (0)
 #endif
 
+extern "C" int __libc_sigaction (int __sig, 
+		      __const struct sigaction *__restrict __act,
+                      struct sigaction *__restrict __oact) throw ();
+
 #define INIT_SEGV						\
 do								\
   {								\
@@ -58,7 +77,7 @@
     act.sa_sigaction = _Jv_catch_segv;      			\
     sigemptyset (&act.sa_mask);					\
     act.sa_flags = SA_SIGINFO;	       				\
-    syscall (SYS_sigaction, SIGSEGV, &act, NULL);		\
+    __libc_sigaction (SIGSEGV, &act, NULL);		\
   }								\
 while (0)  
 
@@ -71,7 +90,7 @@
     act.sa_sigaction = _Jv_catch_fpe;				\
     sigemptyset (&act.sa_mask);					\
     act.sa_flags = SA_SIGINFO;		       			\
-    syscall (SYS_sigaction, SIGFPE, &act, NULL);		\
+    __libc_sigaction (SIGFPE, &act, NULL);		\
   }								\
 while (0)  
 

The last patch shouldn't be checked in.  It has nothing to do with Itanium,
but is a stopgap to allow me to link SPECjbb statically, which unfortunately
makes a substantial performance difference.  It was suggested by someone
else (Bryce?)  I post it here for discussion, since I'm not sure there will
be another solution in 3.1, and I think it is still a real issue.  Is there
a better (e.g. less US-centric) solution we could get into 3.1?

Index: libjava/gnu/gcj/runtime/FirstThread.java
===================================================================
RCS file: /cvs/gcc/gcc/libjava/gnu/gcj/runtime/FirstThread.java,v
retrieving revision 1.10
diff -u -r1.10 FirstThread.java
--- FirstThread.java	2001/10/10 22:25:43	1.10
+++ FirstThread.java	2002/03/14 16:44:18
@@ -94,4 +94,11 @@
   static final Class Kfile = gnu.gcj.protocol.file.Handler.class;
   static final Class Khttp = gnu.gcj.protocol.http.Handler.class;
   static final Class Kjar  = gnu.gcj.protocol.jar.Handler.class;
+
+  // These are also common problems for static linking.
+  static final Class Kcal = gnu.java.locale.Calendar.class;
+  static final Class Kli = gnu.java.locale.LocaleInformation.class;
+  static final Class Kcen = gnu.java.locale.Calendar_en.class;
+  static final Class Klien = gnu.java.locale.LocaleInformation_en.class;
+  static final Class Klienus =
gnu.java.locale.LocaleInformation_en_US.class;
 }


Hans