[RFC PATCH] make libgcj_bc prims symbol sizes correct

[Andrew Haley]

Andrew Haley wrote:
> 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.

Ah, there's a deeper bug here.

BC-compiled executables are being linked against libgcj as well as libgcj_bc.
We've seen this bug before, and we fixed it.

This means that BC-compiled executable are not binary compatible.  This is a
MUSTFIX, and I'll do it next week.

Thanks for the heads up.

Andrew.