Your ia64 patch may have broken libjava

Your ia64 patch may have broken libjava

[H. J. Lu]

Hi David,

Your patch

http://gcc.gnu.org/ml/gcc-cvs/2003-04/msg00033.html

may have caused massive libjava failures on Linux/ia64:

http://gcc.gnu.org/ml/gcc-testresults/2003-03/msg01626.html
http://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00087.html

I have almost narrowed it down to your patch. I couldn't find any
discussions in the gcc-patches archive about your patch. Have you
verified your patch with java enabled on Linux/ia64?


H.J.

Re: Your ia64 patch may have broken libjava

[David Mosberger]

>>>>> On Tue, 6 May 2003 19:54:21 -0700, "H. J. Lu" <hjl@lucon.org> said:

  HJ> Hi David, Your patch

  HJ> http://gcc.gnu.org/ml/gcc-cvs/2003-04/msg00033.html

  HJ> may have caused massive libjava failures on Linux/ia64:

  HJ> http://gcc.gnu.org/ml/gcc-testresults/2003-03/msg01626.html
  HJ> http://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00087.html

Hmmh, I'm sorry (and surprised) to hear that.

  HJ> I have almost narrowed it down to your patch. I couldn't find
  HJ> any discussions in the gcc-patches archive about your
  HJ> patch. Have you verified your patch with java enabled on
  HJ> Linux/ia64?

No, last time I tried (perhaps 3 months ago), gcj/ia64 wasn't even
building, so I ended up configuring just gcc and g++.  I just started
a build with gcj enabled.  Let's see how far it gets.

In the meantime, you may want to try the attached patch.  There should
be no functional change, but it's easier if we all can work off the
latest version of the file.

	--david

--
From: David Mosberger <davidm@linux.hpl.hp.com>
To: rth@redhat.com
cc: gcc-patches@gcc.gnu.org, davidm@linux.hpl.hp.com
Subject: some more ia64/crt{begin,end}.asm cleanup
Date: Fri, 25 Apr 2003 15:13:42 -0700
Reply-to: davidm@hpl.hp.com
X-URL: http://www.hpl.hp.com/personal/David_Mosberger/

Here is some more cleanup for the ia64 versions of crtbegin.asm and
crtend.asm.  As per your suggestion/concern, I tried to get the file
to compile with the Intel assembler (again).  It does work now, with
the exception that I couldn't find a ".section .init_array" syntax
that works both with gas and ias without producing an error or
warning.  I supposed we could add an #ifdef, but I'm not sure anyone
really cares anymore about building with ias, so I didn't want to make
the code needlessly ugly.

Other changes include adding the missing ".prologue" in
__do_jv_register_classes and registering __do_global_ctors_aux() in
crtend.asm, so it can "static" instead of "global" scope.

The patch is relative to the current CVS gcc tree.

Please apply if it looks ok.

Thanks,

	--david

2003-04-25  David Mosberger <davidm@hpl.hp.com>

	* config/ia64/crtbegin.asm (__do_jv_register_classes): Add missing
	.prologue directive.
	Use .skip instead of data8 for .bss section to make Intel
	Assembler (ias) happy.  Minor whitespace fixups.  Make "nop 0"
	explicit in the .mib bundles and remove the unnecessary stop
	bits.  Replace local labels with normal labels, to make ias
	happy.  Don't register __do_global_ctors_aux here, do it in
	crtend.asm instead.

	* config/ia64/crtend.asm [HAVE_INIT_FINI_ARRAY]: Register
	__do_global_ctors_aux in .init_array section instead of
	declaring it as a hidden global.  Replace local labels with
	ordinary labels to make ias happy.

Index: config/ia64/crtbegin.asm
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/ia64/crtbegin.asm,v
retrieving revision 1.15
diff -u -r1.15 crtbegin.asm
--- config/ia64/crtbegin.asm	1 Apr 2003 23:29:34 -0000	1.15
+++ config/ia64/crtbegin.asm	25 Apr 2003 21:18:48 -0000
@@ -48,20 +48,20 @@
 	data8	__dso_handle
 #else
 	.section .bss
+	.align 8
 __dso_handle:
-	data8	0
+	.skip	8
 #endif
 	.hidden __dso_handle
 
 
 #ifdef HAVE_INITFINI_ARRAY
 
-.section .fini_array,"a"
+.section .fini_array, "a"
 	data8 @fptr(__do_global_dtors_aux)
 
-.section .init_array,"a"
+.section .init_array, "a"
 	data8 @fptr(__do_jv_register_classes)
-	data8 @fptr(__do_global_ctors_aux)
 
 #else /* !HAVE_INITFINI_ARRAY */
 /*
@@ -88,9 +88,9 @@
 	  ;;
 	}
 	{ .mib
+	  nop 0
 	  mov b6 = r2
 	  br.call.sptk.many b0 = b6
-	  ;;
 	}
 
 /* Likewise for _init.  */
@@ -106,9 +106,9 @@
 	  ;;
 	}
 	{ .mib
+	  nop 0
 	  mov b6 = r2
 	  br.call.sptk.many b0 = b6
-	  ;;
 	}
 #endif /* !HAVE_INITFINI_ARRAY */
 
@@ -127,8 +127,7 @@
 
 	mov loc2 = gp
 	nop 0
-	br.sptk.many 1f
-	;;
+	br.sptk.many .entry
 #else
 	/*
 		if (__cxa_finalize)
@@ -164,7 +163,7 @@
 
 	nop 0
 	nop 0
-	br.sptk.many 1f
+	br.sptk.many .entry
 #endif
 	/*
 		do {
@@ -172,7 +171,7 @@
 		  (*(dtor_ptr-1)) ();
 		} while (dtor_ptr);
 	*/
-0:
+.loop:
 	st8 [loc0] = r15		// update dtor_ptr (in memory)
 	ld8 r17 = [r16], 8		// r17 <- dtor's entry-point
 	nop 0
@@ -182,7 +181,7 @@
 	mov b6 = r17
 	br.call.sptk.many rp = b6
 
-1: ld8 r15 = [loc0] // r15 <- dtor_ptr (gp-relative) +.entry: ld8 r15
= [loc0] // r15 <- dtor_ptr (gp-relative)
 	;;
 	add r16 = r15, loc2		// r16 <- dtor_ptr (absolute)
 	adds r15 = 8, r15
@@ -194,13 +193,14 @@
 	;;
 
 	cmp.ne p6, p0 = r0, r16
-(p6)	br.cond.sptk.few 0b
+(p6)	br.cond.sptk.few .loop
 	br.ret.sptk.many rp
 	.endp __do_global_dtors_aux
 
 	.align	32
 	.proc	__do_jv_register_classes
 __do_jv_register_classes:
+	.prologue
 	.save ar.pfs, r33
 	alloc loc1 = ar.pfs, 0, 2, 1, 0
 	movl out0 = @gprel(__JCR_LIST__)
Index: config/ia64/crtend.asm
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/ia64/crtend.asm,v
retrieving revision 1.11
diff -u -r1.11 crtend.asm
--- config/ia64/crtend.asm	1 Apr 2003 23:29:35 -0000	1.11
+++ config/ia64/crtend.asm	25 Apr 2003 21:18:48 -0000
@@ -33,7 +33,12 @@
 __JCR_END__:
 	data8	0
 
-#ifndef HAVE_INITFINI_ARRAY
+#ifdef HAVE_INITFINI_ARRAY
+
+.section .init_array, "a"
+	data8 @fptr(__do_global_ctors_aux)
+
+#else /* !HAVE_INITFINI_ARRAY */
 /*
  * Fragment of the ELF _init routine that invokes our dtor cleanup.
  *
@@ -66,12 +71,6 @@
 
 .text
 	.align 32
-#ifdef HAVE_INITFINI_ARRAY
-	/* This is referenced from crtbegin.o.  */
-	.globl __do_global_ctors_aux
-	.type __do_global_ctors_aux,@function
-	.hidden __do_global_ctors_aux
-#endif
 	.proc __do_global_ctors_aux
 __do_global_ctors_aux:
 	.prologue
@@ -94,9 +93,9 @@
 
 	cmp.eq p6, p0 = -1, loc3
 	nop 0
-(p6)	br.cond.spnt.few 2f
+(p6)	br.cond.spnt.few .exit
 
-0:	ld8 r15 = [loc3], 8
+.loop:	ld8 r15 = [loc3], 8
 	;;
 	ld8 gp = [loc3]
 	mov b6 = r15
@@ -108,9 +107,9 @@
 
 	cmp.ne p6, p0 = -1, loc3
 	nop 0
-(p6)	br.cond.sptk.few 0b
+(p6)	br.cond.sptk.few .loop
 
-2:	nop.m 0
+.exit:	nop.m 0
 	mov rp = loc1
 	mov ar.pfs = loc2
 

Re: Your ia64 patch may have broken libjava

[David Mosberger]

>>>>> On Tue, 6 May 2003 19:54:21 -0700, "H. J. Lu" <hjl@lucon.org> said:

  HJ> Your patch

  HJ> http://gcc.gnu.org/ml/gcc-cvs/2003-04/msg00033.html

  HJ> may have caused massive libjava failures on Linux/ia64.

OK, I think I found the culprit: too much gp optimization.  The patch below
is relative to the CVS tree and includes the changes I sent previously plus
the fix to save/restore gp in __do_jv_register_classes().

Unfortunately, I still can't built gcj:

make[1]: Entering directory `/usr/src/misc/gcc-build/ia64-hp-linux/libjava'
make[1]: *** No rule to make target `java/util/prefs/NodeChangeListener.java', needed by `java/util/prefs/NodeChangeListener.class'.  Stop.
make[1]: Leaving directory `/usr/src/misc/gcc-build/ia64-hp-linux/libjava'
make: *** [all-target-libjava] Error 2

Don't know what this is about.  Can you rerun the test with the patch
applied?

	--david

2003-05-06  David Mosberger <davidm@hpl.hp.com>
	* config/ia64/crtbegin.asm (__do_jv_register_classes): Don't forget
	to preserve gp (fixes bug introduced by my 4/25 changes).
	* config/ia64/crtend.asm (__do_global_ctors_au): Ditto.

2003-04-25  David Mosberger <davidm@hpl.hp.com>

	* config/ia64/crtbegin.asm (__do_jv_register_classes): Add missing
	.prologue directive.
	Use .skip instead of data8 for .bss section to make Intel
	Assembler (ias) happy.  Minor whitespace fixups.  Make "nop 0"
	explicit in the .mib bundles and remove the unnecessary stop
	bits.  Replace local labels with normal labels, to make ias
	happy.  Don't register __do_global_ctors_aux here, do it in
	crtend.asm instead.

	* config/ia64/crtend.asm [HAVE_INIT_FINI_ARRAY]: Register
	__do_global_ctors_aux in .init_array section instead of
	declaring it as a hidden global.  Replace local labels with
	ordinary labels to make ias happy.

Index: config/ia64/crtbegin.asm
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/ia64/crtbegin.asm,v
retrieving revision 1.15
diff -u -r1.15 crtbegin.asm
--- config/ia64/crtbegin.asm	1 Apr 2003 23:29:34 -0000	1.15
+++ config/ia64/crtbegin.asm	7 May 2003 05:43:50 -0000
@@ -48,20 +48,20 @@
 	data8	__dso_handle
 #else
 	.section .bss
+	.align 8
 __dso_handle:
-	data8	0
+	.skip	8
 #endif
 	.hidden __dso_handle
 
 
 #ifdef HAVE_INITFINI_ARRAY
 
-.section .fini_array,"a"
+.section .fini_array, "a"
 	data8 @fptr(__do_global_dtors_aux)
 
-.section .init_array,"a"
+.section .init_array, "a"
 	data8 @fptr(__do_jv_register_classes)
-	data8 @fptr(__do_global_ctors_aux)
 
 #else /* !HAVE_INITFINI_ARRAY */
 /*
@@ -88,9 +88,9 @@
 	  ;;
 	}
 	{ .mib
+	  nop 0
 	  mov b6 = r2
 	  br.call.sptk.many b0 = b6
-	  ;;
 	}
 
 /* Likewise for _init.  */
@@ -106,9 +106,9 @@
 	  ;;
 	}
 	{ .mib
+	  nop 0
 	  mov b6 = r2
 	  br.call.sptk.many b0 = b6
-	  ;;
 	}
 #endif /* !HAVE_INITFINI_ARRAY */
 
@@ -127,8 +127,7 @@
 
 	mov loc2 = gp
 	nop 0
-	br.sptk.many 1f
-	;;
+	br.sptk.many .entry
 #else
 	/*
 		if (__cxa_finalize)
@@ -164,7 +163,7 @@
 
 	nop 0
 	nop 0
-	br.sptk.many 1f
+	br.sptk.many .entry
 #endif
 	/*
 		do {
@@ -172,7 +171,7 @@
 		  (*(dtor_ptr-1)) ();
 		} while (dtor_ptr);
 	*/
-0:
+.loop:
 	st8 [loc0] = r15		// update dtor_ptr (in memory)
 	ld8 r17 = [r16], 8		// r17 <- dtor's entry-point
 	nop 0
@@ -182,7 +181,7 @@
 	mov b6 = r17
 	br.call.sptk.many rp = b6
 
-1:	ld8 r15 = [loc0]		// r15 <- dtor_ptr (gp-relative)
+.entry:	ld8 r15 = [loc0]		// r15 <- dtor_ptr (gp-relative)
 	;;
 	add r16 = r15, loc2		// r16 <- dtor_ptr (absolute)
 	adds r15 = 8, r15
@@ -194,15 +193,16 @@
 	;;
 
 	cmp.ne p6, p0 = r0, r16
-(p6)	br.cond.sptk.few 0b
+(p6)	br.cond.sptk.few .loop
 	br.ret.sptk.many rp
 	.endp __do_global_dtors_aux
 
 	.align	32
 	.proc	__do_jv_register_classes
 __do_jv_register_classes:
+	.prologue
 	.save ar.pfs, r33
-	alloc loc1 = ar.pfs, 0, 2, 1, 0
+	alloc loc1 = ar.pfs, 0, 3, 1, 0
 	movl out0 = @gprel(__JCR_LIST__)
 	;;
 
@@ -224,15 +224,15 @@
 
 	ld8 r15 = [r14], 8
 	;;
-	ld8 gp = [r14]
+	nop 0
 	mov b6 = r15
 
-	nop 0
-	nop 0
+	mov loc2 = gp
+	ld8 gp = [r14]
 	br.call.sptk.many rp = b6
 	;;
 
-	nop 0
+	mov gp = loc2
 	mov rp = loc0
 	mov ar.pfs = loc1
 
Index: config/ia64/crtend.asm
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/ia64/crtend.asm,v
retrieving revision 1.11
diff -u -r1.11 crtend.asm
--- config/ia64/crtend.asm	1 Apr 2003 23:29:35 -0000	1.11
+++ config/ia64/crtend.asm	7 May 2003 05:43:50 -0000
@@ -33,7 +33,12 @@
 __JCR_END__:
 	data8	0
 
-#ifndef HAVE_INITFINI_ARRAY
+#ifdef HAVE_INITFINI_ARRAY
+
+.section .init_array, "a"
+	data8 @fptr(__do_global_ctors_aux)
+
+#else /* !HAVE_INITFINI_ARRAY */
 /*
  * Fragment of the ELF _init routine that invokes our dtor cleanup.
  *
@@ -66,12 +71,6 @@
 
 .text
 	.align 32
-#ifdef HAVE_INITFINI_ARRAY
-	/* This is referenced from crtbegin.o.  */
-	.globl __do_global_ctors_aux
-	.type __do_global_ctors_aux,@function
-	.hidden __do_global_ctors_aux
-#endif
 	.proc __do_global_ctors_aux
 __do_global_ctors_aux:
 	.prologue
@@ -80,7 +79,7 @@
 		  (*p) ();
 	*/
 	.save ar.pfs, r34
-	alloc loc2 = ar.pfs, 0, 4, 0, 0
+	alloc loc2 = ar.pfs, 0, 5, 0, 0
 	movl loc0 = @gprel(__CTOR_END__ - 8)
 	;;
 
@@ -93,10 +92,10 @@
 	;;
 
 	cmp.eq p6, p0 = -1, loc3
-	nop 0
-(p6)	br.cond.spnt.few 2f
+	mov loc4 = gp
+(p6)	br.cond.spnt.few .exit
 
-0:	ld8 r15 = [loc3], 8
+.loop:	ld8 r15 = [loc3], 8
 	;;
 	ld8 gp = [loc3]
 	mov b6 = r15
@@ -108,9 +107,9 @@
 
 	cmp.ne p6, p0 = -1, loc3
 	nop 0
-(p6)	br.cond.sptk.few 0b
+(p6)	br.cond.sptk.few .loop
 
-2:	nop.m 0
+.exit:	mov gp = loc3
 	mov rp = loc1
 	mov ar.pfs = loc2
 

Re: Your ia64 patch may have broken libjava

[Andreas Jaeger]

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

David Mosberger <davidm@napali.hpl.hp.com> writes:

>>>>>> On Tue, 6 May 2003 19:54:21 -0700, "H. J. Lu" <hjl@lucon.org> said:
>
>   HJ> Your patch
>
>   HJ> http://gcc.gnu.org/ml/gcc-cvs/2003-04/msg00033.html
>
>   HJ> may have caused massive libjava failures on Linux/ia64.
>
> OK, I think I found the culprit: too much gp optimization.  The patch below
> is relative to the CVS tree and includes the changes I sent previously plus
> the fix to save/restore gp in __do_jv_register_classes().
>
> Unfortunately, I still can't built gcj:
>
> make[1]: Entering directory `/usr/src/misc/gcc-build/ia64-hp-linux/libjava'
> make[1]: *** No rule to make target `java/util/prefs/NodeChangeListener.java', needed by `java/util/prefs/NodeChangeListener.class'.  Stop.
> make[1]: Leaving directory `/usr/src/misc/gcc-build/ia64-hp-linux/libjava'
> make: *** [all-target-libjava] Error 2
>
> Don't know what this is about.  Can you rerun the test with the patch
> applied?

Run contrib/gcc_update to update your tree instead of a simple cvs
update, I expect that you're missing some new directories.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Your ia64 patch may have broken libjava

[David Mosberger]

>>>>> On Wed, 07 May 2003 08:16:14 +0200, Andreas Jaeger <aj@suse.de> said:

  Andreas> Run contrib/gcc_update to update your tree instead of a simple cvs
  Andreas> update, I expect that you're missing some new directories.

Yes, that was indeed the problem.  Thanks for the tip!

It gets much further now.  Then it dies with:

$ /usr/src/misc/gcc-build/gcc/gcj -B/usr/src/misc/gcc-build/ia64-hp-linux/libjava/ -B/usr/src/misc/gcc-build/gcc/ -funwind-tables -g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc  -L/usr/src/misc/gcc-build/ia64-hp-linux/libjava -L/usr/src/misc/gcc-build/ia64-hp-linux/libjava/.libs ./.libs/libgcj.so -L/usr/src/misc/gcc-build/ia64-hp-linux/libstdc++-v3/src -L/usr/src/misc/gcc-build/ia64-hp-linux/libstdc++-v3/src/.libs -lpthread -ldl -lz -L/usr/src/misc/gcc-build/gcc -L/opt/gcc-pre3.4/lib/gcc-lib/ia64-hp-linux/3.4 -L/opt/gcc-pre3.4/lib/gcc-lib/ia64-hp-linux/3.4/../../.. -lgcc_s -lunwind -lc -lgcc_s -lunwind -Wl,--rpath -Wl,/opt/gcc-pre3.4/lib
./.libs/libgcj.so: undefined reference to `_Unwind_FindEnclosingFunction'
collect2: ld returned 1 exit status

Looks like this may be something that needs to be added to
unwind-libunwind.c.  But it's getting late here, so I'm afraid I'm
gonna have to call it a day for now.  I'll try to look into it
tomorrow.

	--david

Re: Your ia64 patch may have broken libjava

[Andrew Haley]

David Mosberger writes:
 > 
 > Looks like [_Unwind_FindEnclosingFunction'] may be something that needs to be added to
 > unwind-libunwind.c.  But it's getting late here, so I'm afraid I'm
 > gonna have to call it a day for now.  I'll try to look into it
 > tomorrow.

I think so; it's a very simple function.  I guess no-one is building
gcj on 3.3 branch for IA-64 either?

Andrew.

Re: Your ia64 patch may have broken libjava

[Andreas Jaeger]

Andrew Haley <aph@redhat.com> writes:

> David Mosberger writes:
>  > 
>  > Looks like [_Unwind_FindEnclosingFunction'] may be something that needs to be added to
>  > unwind-libunwind.c.  But it's getting late here, so I'm afraid I'm
>  > gonna have to call it a day for now.  I'll try to look into it
>  > tomorrow.
>
> I think so; it's a very simple function.  I guess no-one is building
> gcj on 3.3 branch for IA-64 either?

Andreas Schwab does,e.g:
http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00343.html

Those reults look fine to me,
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Your ia64 patch may have broken libjava

[Andrew Haley]

Andreas Jaeger writes:
 > Andrew Haley <aph@redhat.com> writes:
 > 
 > > David Mosberger writes:
 > >  > 
 > >  > Looks like [_Unwind_FindEnclosingFunction'] may be something that needs to be added to
 > >  > unwind-libunwind.c.  But it's getting late here, so I'm afraid I'm
 > >  > gonna have to call it a day for now.  I'll try to look into it
 > >  > tomorrow.
 > >
 > > I think so; it's a very simple function.  I guess no-one is building
 > > gcj on 3.3 branch for IA-64 either?
 > 
 > Andreas Schwab does,e.g:
 > http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00343.html
 > 
 > Those reults look fine to me,

Me too; TVM for the info.  I guess David will find out the reason for
the difference.

Andrew.

Re: Your ia64 patch may have broken libjava

[H. J. Lu]

On Tue, May 06, 2003 at 10:47:22PM -0700, David Mosberger wrote:
> >>>>> On Tue, 6 May 2003 19:54:21 -0700, "H. J. Lu" <hjl@lucon.org> said:
> 
>   HJ> Your patch
> 
>   HJ> http://gcc.gnu.org/ml/gcc-cvs/2003-04/msg00033.html
> 
>   HJ> may have caused massive libjava failures on Linux/ia64.
> 
> OK, I think I found the culprit: too much gp optimization.  The patch below
> is relative to the CVS tree and includes the changes I sent previously plus
> the fix to save/restore gp in __do_jv_register_classes().
> 

Yes, it fixed the problem. Could someone please check it in?

Thanks.


H.J.

Re: Your ia64 patch may have broken libjava

[David Mosberger]

>>>>> On Wed, 7 May 2003 10:17:04 +0100, Andrew Haley <aph@redhat.com> said:

  Andrew> David Mosberger writes:
  >>  Looks like [_Unwind_FindEnclosingFunction'] may be something
  >> that needs to be added to unwind-libunwind.c.  But it's getting
  >> late here, so I'm afraid I'm gonna have to call it a day for now.
  >> I'll try to look into it tomorrow.

  Andrew> I think so; it's a very simple function.  I guess no-one is
  Andrew> building gcj on 3.3 branch for IA-64 either?

I think it means nobody built 3.3 with libunwind.  Not surprising
given that libunwind packages have started to become available only
recently (e.g., http://www.esiee.fr/~delahaym/).  I think the
situation may change fairly quickly though, especially as gdb/ia64
starts to get built against libunwind.

	--david

Re: Your ia64 patch may have broken libjava

[Andrew Haley]

David Mosberger writes:
 > >>>>> On Wed, 7 May 2003 10:17:04 +0100, Andrew Haley <aph@redhat.com> said:
 > 
 >   Andrew> David Mosberger writes:
 >   >>  Looks like [_Unwind_FindEnclosingFunction'] may be something
 >   >> that needs to be added to unwind-libunwind.c.  But it's getting
 >   >> late here, so I'm afraid I'm gonna have to call it a day for now.
 >   >> I'll try to look into it tomorrow.
 > 
 >   Andrew> I think so; it's a very simple function.  I guess no-one is
 >   Andrew> building gcj on 3.3 branch for IA-64 either?
 > 
 > I think it means nobody built 3.3 with libunwind.  Not surprising
 > given that libunwind packages have started to become available only
 > recently (e.g., http://www.esiee.fr/~delahaym/).  I think the
 > situation may change fairly quickly though, especially as gdb/ia64
 > starts to get built against libunwind.

I'm very interested in libunwind for IA-64 because it should give me
a clean way to get a stack trace.  Stack traces don't work on IA-64
gcj at the moment, and that causes a ton of problems.

Andrew.

Re: Your ia64 patch may have broken libjava

[David Mosberger]

>>>>> On Wed, 7 May 2003 19:04:54 +0100, Andrew Haley <aph@redhat.com> said:

  Andrew> I'm very interested in libunwind for IA-64 because it should
  Andrew> give me a clean way to get a stack trace.  Stack traces
  Andrew> don't work on IA-64 gcj at the moment, and that causes a ton
  Andrew> of problems.

Glad to hear that.  At the moment, I'm not aware of libunwind RPMs but
if someone makes them available, I'd be happy to add a link to them on
the libunwind web site (http://www.hpl.hp.com/research/linux/libunwind/).
Also, you might want to check with Jeff Johnston at Red Hat.  He is
working on integrating libunwind into gdb, so he might already have some
RPMs.

On the _Unwind_FindEnclosingFunction() issue: I found that
config/ia64/libunwind-ia64.c simply defines it as a dummy function
returning NULL.  The patch below does the same for unwind-libunwind.c.
However, I do wonder whether this is really the right solution.  Isn't
this used for some sort of security check?  Is it really OK to always
return NULL in this function?

In the meantime, would someone be so kind to check in the attached
patch?

Thanks,

	--david

2003-03-31  David Mosberger <davidm@hpl.hp.com>

	* unwind-libunwind.c (_Unwind_FindEnclosingFunction): New
          function.

Index: gcc/unwind-libunwind.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/unwind-libunwind.c,v
retrieving revision 1.5
diff -u -r1.5 unwind-libunwind.c
--- gcc/unwind-libunwind.c	3 Apr 2003 02:06:55 -0000	1.5
+++ gcc/unwind-libunwind.c	7 May 2003 18:20:15 -0000
@@ -161,6 +161,12 @@
   return (_Unwind_Ptr) pi.start_ip;
 }
 
+void *
+_Unwind_FindEnclosingFunction (void *pc)
+{
+  return NULL;
+}
+
 #include "unwind.inc"
 
 #endif /* !__USING_SJLJ_EXCEPTIONS__ */

Re: Your ia64 patch may have broken libjava

[Andrew Haley]

David Mosberger writes:
 > >>>>> On Wed, 7 May 2003 19:04:54 +0100, Andrew Haley <aph@redhat.com> said:
 > 
 >   Andrew> I'm very interested in libunwind for IA-64 because it should
 >   Andrew> give me a clean way to get a stack trace.  Stack traces
 >   Andrew> don't work on IA-64 gcj at the moment, and that causes a ton
 >   Andrew> of problems.
 > 
 > Glad to hear that.  At the moment, I'm not aware of libunwind RPMs but
 > if someone makes them available, I'd be happy to add a link to them on
 > the libunwind web site (http://www.hpl.hp.com/research/linux/libunwind/).
 > Also, you might want to check with Jeff Johnston at Red Hat.  He is
 > working on integrating libunwind into gdb, so he might already have some
 > RPMs.
 > 
 > On the _Unwind_FindEnclosingFunction() issue: I found that
 > config/ia64/libunwind-ia64.c simply defines it as a dummy function
 > returning NULL.  The patch below does the same for unwind-libunwind.c.
 > However, I do wonder whether this is really the right solution.  Isn't
 > this used for some sort of security check?

It is, but we need stack traces to work first.

Andrew.

Re: Your ia64 patch may have broken libjava

[H. J. Lu]

With your lastest patch applied, I got

http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00440.html

It looks OK.


H.J.

Re: Your ia64 patch may have broken libjava

[Andrew Haley]

H. J. Lu writes:
 > With your lastest patch applied, I got
 > 
 > http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00440.html
 > 
 > It looks OK.

It's not just OK, it's close to the best set of gcj test results that
I have ever seen.

Andrew.

Re: Your ia64 patch may have broken libjava

[David Mosberger]

>>>>> On Wed, 7 May 2003 13:11:33 -0700, "H. J. Lu" <hjl@lucon.org> said:

  HJ> With your lastest patch applied, I got
  HJ> http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00440.html

  HJ> It looks OK.

Good.  And sorry about the breakage.

	--david

Re: Your ia64 patch may have broken libjava

[Richard Henderson]

On Tue, May 06, 2003 at 10:47:22PM -0700, David Mosberger wrote:
> 	* config/ia64/crtbegin.asm (__do_jv_register_classes): Don't forget
> 	to preserve gp (fixes bug introduced by my 4/25 changes).
> 	* config/ia64/crtend.asm (__do_global_ctors_au): Ditto.
> 
> 	* config/ia64/crtbegin.asm (__do_jv_register_classes): Add missing
> 	.prologue directive.
> 	Use .skip instead of data8 for .bss section to make Intel
> 	Assembler (ias) happy.  Minor whitespace fixups.  Make "nop 0"
> 	explicit in the .mib bundles and remove the unnecessary stop
> 	bits.  Replace local labels with normal labels, to make ias
> 	happy.  Don't register __do_global_ctors_aux here, do it in
> 	crtend.asm instead.
> 
> 	* config/ia64/crtend.asm [HAVE_INIT_FINI_ARRAY]: Register
> 	__do_global_ctors_aux in .init_array section instead of
> 	declaring it as a hidden global.  Replace local labels with
> 	ordinary labels to make ias happy.

Applied.


r~