[Linux-ia64] gcj build on Itanium

[Linux-ia64] gcj build on Itanium

[Boehm, Hans]

I attempted to build gcc (roughly CVS version, as of about a week ago),
including the java support, on a machine with the 11/17 tool chain
installed.  I had successfully built gcj on Itanium a long time ago.  But
there seems to have been some bit rot.

I've gotten to the point where I can again barely run the hello world
program.  I'm still working on making this usable again.  But I ran into a
number of problems for which I would have trouble generating a proper patch
without some help.  And some of them look like they might have implications
for other things.  So here's a list of what I've run into so far:

Problem 1: java/jcf-io.c in the Java front end is misoptimized by the 11/17
compiler.  The problem appears to be with the inlined strcpy call in
find_class.

Workaround: Don't optimize it.  (This is probably not worth fixing unless
it's still broken in the CVS toolchain, which I haven't checked.)

Problem 2: The build process had trouble finding the libgcc_s.so.0 it just
built.

Workaround: I hacked in the right linker option.

Request: Could someone fix this properly, if it is indeed just a build
problem.

Problem 3: Finally clauses are now miscompiled by the Itanium gcj.  The code
generates references to undefined labels, as in "addl r14=@ltoff(.L837),gp"
with no definition of .L837.

Workaround: I temporarily removed the offending "finally" clauses from
ObjectInputStream.java and ObjectOutputStream.java.  This allows Java
programs to link at a minor cost in correctness :-) .

Request: Could someone who understands gcc exception handling check that
exception handling is configured sanely for Java?  I suspect that Java uses
setjmp/longjmp exception handling, which is different from C++, and probably
wrong.  Why does setjmp/longjmp excetpion handling result in incorrect code
for try/finally?

Problem 4: Linking Java applications dynamically results in "@gprel
relocation against dynamic symbol java::lang::System::out".  As far as I can
tell, java/lang/System.java defines the symbol, and is compiled with -fPIC.

Question: Should the fron end be doing something it isn't in order to deal
with sdata symbols?  Is -fPIC different from -fpic on Itanium?

Problem 5: Static linking tends to result in "eh.o...: undefined reference
to `fwrite'.  This seems to be a library ordering problem, which might also
affect other platforms.

Workaround: use "-u fwrite" on the command line.

Request: What's a proper fix?

Problem 6: -save-temps doesn't save the main program .o file.  This seems
like an oversight, which is mildly annoying when debugging gcj.

Request: A fix? (low priority)

Problem 7: Generated executables die imeediately in the garbage collector,
since the main process stack location is no longer at the fixed location
hardcoded into the GC for Itanium.  (This was a kernel change from a few
months ago.)

Patch: (Don't use with NUE simulator.)
Index: gcconfig.h
=================================RCS file: /cvs/gcc/gcc/boehm-gc/gcconfig.h,v
retrieving revision 1.15
diff -u -r1.15 gcconfig.h
--- gcconfig.h	2000/12/10 22:57:37	1.15
+++ gcconfig.h	2001/02/27 01:05:22
@@ -1116,11 +1116,20 @@
 #       define CPP_WORDSZ 64
 	/* This should really be done through /proc, but that	*/
 	/* requires we run on an IA64 kernel.			*/
-#       define STACKBOTTOM ((ptr_t) 0xa000000000000000l)
+	/* The following works on old NUE and older kernels:	*/
+/* #       define STACKBOTTOM ((ptr_t) 0xa000000000000000l)	*/
+	/* This does not work on NUE:				*/
+#       define LINUX_STACKBOTTOM
 	/* We also need the base address of the register stack	*/
-	/* backing store.  There is probably a better way to	*/
-	/* get that, too ...					*/
-#	define BACKING_STORE_BASE ((ptr_t) 0x9fffffff80000000l)
+	/* backing store.  There should be a better way to get	*/
+	/* this:						*/
+#	define APPROX_BS_BASE ((word)GC_stackbottom-0x80000000)
+	/* We round to the next multiple of 1 MB, to compensate	*/
+	/* for the fact that the stack base is displaced by	*/
+	/* the environment, etc.				*/
+#	define BACKING_STORE_BASE \
+		(ptr_t)((APPROX_BS_BASE + 0xfffff) & ~0xfffff)
+
 #	if 1
 #	    define SEARCH_FOR_DATA_START
 #	    define DATASTART GC_data_start

Re: [Linux-ia64] gcj build on Itanium

[Jim Wilson]

>I attempted to build gcc (roughly CVS version, as of about a week ago),

You should use the gcc3 branch instead of the gcc trunk.  Potentially unsafe
patches were deferred the last few months in preparation for gcc3 release work,
and now that we have the release branch, those patches are going onto the
trunk.  Thus the release branch will be much more stable than the trunk.
Also, it is more important to get the release branch working than the trunk.
The branch name is gcc-3_0-branch.

>  Is -fPIC different from -fpic on Itanium?

No.

That is about all I can do at the moment.  I'm at IDF this week, and hence
not able to do much real work.  I may be able to provide assistance on some
of the problems that are IA-64 back-end specific after IDF ends.

Jim