Re: [RFC PATCH] make libgcj_bc prims symbol sizes correct

Nix wrote:
> Way back in 2006, in
> <http://gcc.gnu.org/ml/java-patches/2006-q3/msg00342.html>, you said, of
> the evil trick whereby DECLARE_PRIM_TYPE declares an int in libgcj_bc.so
> but a Class * in libgcj itself:
> 
>> I'm a little surprised this works -- I would have expected that
>> something (ld?  ld.so?), would want the objects to have the proper
>> size.  However, this doesn't seem to be the case.
> 
> Well, it's stopped working :( on my Linux x86_64/eglibc-2.10 box, GCC
> 4.4's testsuite says this in every test that pulls in one of the
> primitive types (e.g. Array_1 and a whole lot more):
> 
> /usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/libjava/testsuite/Array_1.exe: Symbol `_Jv_intClass' has different size in shared object, consider re-linking
> 
> Then it dumps core:
> 
> Program terminated with signal 6, Aborted.
> [New process 20396]
> [New process 20398]
> #0  0x00007f84e5603d75 in raise () from /lib/libc.so.6
> (gdb) bt
> #0  0x00007f84e5603d75 in raise () from /lib/libc.so.6
> #1  0x00007f84e56069ff in *__GI_abort () at abort.c:88
> #2  0x00007f84e3a1181b in _Jv_Throw (value=0x7f84e5cde2f8) at /usr/src/gcc/4.4-090813/libjava/exception.cc:128
> #3  0x00007f84e3a058ba in _Jv_catch_segv (_p=<value optimized out>) at /usr/src/gcc/4.4-090813/libjava/prims.cc:184
> #4  <signal handler called>
> #5  0x0000000000000000 in ?? ()
> #6  0x0000000000400b97 in Array_1.main(java.lang.String[])void () at Array_1.java:16
> #7  0x00007f84e3a40e1a in gnu::java::lang::MainThread::call_main (this=0x7f84e5bb1dc0) at /usr/src/gcc/4.4-090813/libjava/gnu/java/lang/natMainThread.cc:54
> #8  0x00007f84e3aa2c34 in gnu.java.lang.MainThread.run()void (this=0x7f84e5bb1dc0) at /usr/src/gcc/4.4-090813/libjava/gnu/java/lang/MainThread.java:106
> #9  0x00007f84e3a516fa in _Jv_ThreadRun (thread=0x7f84e5bb1dc0) at /usr/src/gcc/4.4-090813/libjava/java/lang/natThread.cc:335
> #10 0x00007f84e3a05fe5 in _Jv_RunMain (vm_args=<value optimized out>, klass=0x0, name=<value optimized out>, argc=1, argv=0x7f84e17d3fc0, is_jar=<value optimized out>) at /usr/src/gcc/4.4-090813/libjava/prims.cc:1789
> #11 0x00007f84e55f0a7d in __libc_start_main () from /lib/libc.so.6
> #12 0x0000000000400919 in _start ()
> 
> This is with GNU ld 2.19.1.20090202. Obviously the dynamic linker is
> complaining, not the linker itself, but whichever it is, this trick will
> obviously no longer work. We need to get the sizes of symbols right.

Maybe.  But only part of the test uses libgcj_bc, so I can't understand why all
the tests are failing.

> Obviously it is not sane nor portable to hardwire type sizes: so the
> right approach is probably to compile libgcj_bc.c with the same compiler
> as is used for prims.cc and duplicate the type properly, which means
> renaming it to libgcj_bc.cc, including <java/lang/Class.h>, and,
> unfortunately, fixing up all the prototypes :/
> 
> 
> Fix (against 4.4 branch head) attached, following which all libjava
> tests pass (actually these are the cleanest test results I've ever seen
> from GCC, people are doing a really good job XFAILing known-broken
> stuff). Not posted to -patches because I really really doubt that this
> is even vaguely tolerable, even though it works. Please please can
> someone think of something less ugly?

Mmm, we can't use this approach because it hard-wires the size of Class
instances, thus partly losing the advantage of BC compilcation.

I'd love to have a dig at this myself but I can't see any way to duplicate
the problem.

Andrew.