[Linux-ia64] gcj build on Itanium

Boehm, Hans
2001-02-27T01:16:00Z

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