[RFC PATCH] make libgcj_bc prims symbol sizes correct

[RFC PATCH] make libgcj_bc prims symbol sizes correct

[Nix]

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.

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?

(The commented-out things are there as a reminder that these are part of
the libgcj_bc ABI, but happen to be provided by inlines in the header
files now, so cannot be redeclared.)

Downside: everything that <java/lang/Class.h> declares as a non-static
extern inline will now land in libgcj_bc.so as well. I think this is
probably better than a core dump...

2009-08-15  Nix  <nix@esperi.org.uk>

	* libgcj_bc.c: Rename to...
	* libgcj_bc.cc: ... this, adjusting prototypes and inclusions.
	* libgcj_bc.cc (DECLARE_PRIM_TYPE): Use definition from prims.cc.
	* Makefile.am (libgcj_bc_la_SOURCES): Adjust correspondingly.
	* Makefile.in (libgcj_bc_la_SOURCES): Likewise.

Index: gcc/libjava/libgcj_bc.c
===================================================================
--- gcc.orig/libjava/libgcj_bc.c	2009-08-15 01:01:28.000000000 +0100
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,114 +0,0 @@
-/* libgcj_bc.c  */
-
-/* Copyright (C) 2006, 2009 Free Software Foundation
-
-   This file is part of libgcj.
-
-This software is copyrighted work licensed under the terms of the
-Libgcj License.  Please consult the file "LIBGCJ_LICENSE" for
-details.  */
-
-/* This file is used to build libgcj_bc.so, a 'fake' library that is
-   used at link time only. It ensures that binaries built with the
-   BC-ABI link against a constant SONAME. This way, BC-ABI binaries
-   continue to work if the SONAME underlying libgcj.so changes.  */
-
-#include <stdlib.h>
-#include <stdio.h>
-
-static void print_wrong_lib_msg ()
-{
-  fprintf (stderr, "libgcj error: \
-This is libgcj_bc.so, a fake library used only for linking.\n\
-Please create a symlink from libgcj_bc.so.1 to the real libgcj.so.\n");
-  exit (1);
-}
-
-/* Functions called from code generated by gcj.  */
-
-void _Jv_AllocObject () {}
-void _Jv_AllocObjectNoFinalizer () {}
-void _Jv_CheckArrayStore () {}
-void _Jv_CheckCast () {}
-void _Jv_InitClass () {}
-void _Jv_IsInstanceOf () {}
-void _Jv_LookupInterfaceMethod () {}
-void _Jv_LookupInterfaceMethodIdx () {}
-void _Jv_MonitorEnter () {}
-void _Jv_MonitorExit () {}
-void _Jv_NewMultiArray () {}
-void _Jv_NewObjectArray () {}
-void _Jv_NewPrimArray () {}
-void _Jv_RegisterResource () {}
-void _Jv_ResolvePoolEntry () {}
-void _Jv_Throw () {}
-void _Jv_ThrowAbstractMethodError () {}
-void _Jv_ThrowBadArrayIndex () {}
-void _Jv_ThrowNoSuchFieldError () {}
-void _Jv_ThrowNullPointerException () {}
-void __gcj_personality_v0 () {}
-
-void _Jv_RegisterClasses () 
-{
-  print_wrong_lib_msg ();
-}
-
-void _Jv_RegisterNewClasses () 
-{
-  print_wrong_lib_msg ();
-}
-
-/* Symbols used by jvgenmain (-fmain).  */
-
-void JvRunMain () {}
-void JvRunMainName () {}
-const char **_Jv_Compiler_Properties;
-
-/* Functions used by -fjni.  */
-
-void _Jv_GetJNIEnvNewFrame () {}
-void _Jv_LookupJNIMethod () {}
-void _Jv_UnwrapJNIweakReference () {}
-void _Jv_JNI_PopSystemFrame () {}
-
-
-/* Checked divide (-fuse-divide-subroutine).  */
-
-void _Jv_divI () {}
-void _Jv_divJ () {}
-void _Jv_remI () {}
-void _Jv_remJ () {}
-
-
-/* CNI Functions.  */
-
-void _Jv_AllocBytes () {}
-void _Jv_AllocString () {}
-void _Jv_AttachCurrentThread () {}
-void _Jv_AttachCurrentThreadAsDaemon () {}
-void _Jv_CreateJavaVM () {}
-void _Jv_DetachCurrentThread () {}
-void _Jv_Free () {}
-void _Jv_GetStringUTFLength () {}
-void _Jv_GetStringUTFRegion () {}
-void _Jv_Malloc () {}
-void _Jv_NewString () {}
-void _Jv_NewStringLatin1 () {}
-void _Jv_NewStringUTF () {}
-void _Jv_Realloc () {}
-
-
-/* Classes for primitive types.  */
-
-#define DECLARE_PRIM_TYPE(NAME)			\
-  int _Jv_##NAME##Class;
-
-DECLARE_PRIM_TYPE(byte)
-DECLARE_PRIM_TYPE(short)
-DECLARE_PRIM_TYPE(int)
-DECLARE_PRIM_TYPE(long)
-DECLARE_PRIM_TYPE(boolean)
-DECLARE_PRIM_TYPE(char)
-DECLARE_PRIM_TYPE(float)
-DECLARE_PRIM_TYPE(double)
-DECLARE_PRIM_TYPE(void)
Index: gcc/libjava/libgcj_bc.cc
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ gcc/libjava/libgcj_bc.cc	2009-08-15 01:04:21.734930987 +0100
@@ -0,0 +1,118 @@
+/* libgcj_bc.cc  */
+
+/* Copyright (C) 2006, 2009 Free Software Foundation
+
+   This file is part of libgcj.
+
+This software is copyrighted work licensed under the terms of the
+Libgcj License.  Please consult the file "LIBGCJ_LICENSE" for
+details.  */
+
+/* This file is used to build libgcj_bc.so, a 'fake' library that is
+   used at link time only. It ensures that binaries built with the
+   BC-ABI link against a constant SONAME. This way, BC-ABI binaries
+   continue to work if the SONAME underlying libgcj.so changes.  */
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <java/lang/Class.h>
+
+static void print_wrong_lib_msg ()
+{
+  fprintf (stderr, "libgcj error: \
+This is libgcj_bc.so, a fake library used only for linking.\n\
+Please create a symlink from libgcj_bc.so.1 to the real libgcj.so.\n");
+  exit (1);
+}
+
+/* Functions called from code generated by gcj.  */
+
+extern "C"
+{
+  jobject _Jv_AllocObject (jclass) { return NULL; }
+  jobject _Jv_AllocObjectNoFinalizer (jclass) { return NULL; }
+  void _Jv_CheckArrayStore (jobject, jobject) {}
+  void *_Jv_CheckCast (jclass, jobject) { return NULL; }
+  //  In the ABI, provided by an extern inline.
+  //  void _Jv_InitClass (jclass) {}
+  jboolean _Jv_IsInstanceOf(jobject, jclass) { return 0; }
+  void *_Jv_LookupInterfaceMethod (jclass, void *, void *) { return NULL; }
+  void *_Jv_LookupInterfaceMethodIdx (jclass, jclass, int) { return NULL; }
+  void _Jv_MonitorEnter (jobject) {}
+  void _Jv_MonitorExit (jobject) {}
+  jobject _Jv_NewMultiArray (jclass, jint, ...) { return NULL; }
+  jobjectArray _Jv_NewObjectArray(jsize, jclass, jobject) { return NULL; }
+  jobject _Jv_NewPrimArray (jclass, jint) { return NULL; }
+  void *_Jv_ResolvePoolEntry (jclass, jint) { return NULL; }
+  void _Jv_Throw (jthrowable) { exit (0); }
+  void _Jv_ThrowAbstractMethodError () { exit (0); }
+  void _Jv_ThrowBadArrayIndex (jint)  { exit (0); }
+  void _Jv_ThrowNoSuchFieldError (int) { exit (0); }
+  void _Jv_ThrowNullPointerException (void) { exit (0); }
+  void __gcj_personality_v0 () {}
+
+  void _Jv_RegisterClasses (const jclass *)
+  {
+    print_wrong_lib_msg ();
+  }
+
+  void _Jv_RegisterNewClasses (char **)
+  {
+    print_wrong_lib_msg ();
+  }
+
+  /* Symbols used by jvgenmain (-fmain).  */
+
+  void JvRunMain (jclass, int, const char **) {}
+  void JvRunMainName (const char *, int, const char **) {}
+  const char **_Jv_Compiler_Properties;
+
+  /* Functions used by -fjni.  */
+
+  void * _Jv_GetJNIEnvNewFrame (jclass) { return NULL; }
+  void *_Jv_LookupJNIMethod (jclass, _Jv_Utf8Const, _Jv_Utf8Const *, int) { return NULL; }
+  jobject _Jv_UnwrapJNIweakReference (jobject) { return NULL; }
+  void _Jv_JNI_PopSystemFrame (void *) {}
+
+
+  /* Checked divide (-fuse-divide-subroutine).  */
+
+  jint _Jv_divI (jint, jint) { return 0; }
+  jlong _Jv_divJ (jlong, jlong) { return 0; }
+  jint _Jv_remI (jint, jint) { return 0; }
+  jlong _Jv_remJ (jlong, jlong) { return 0; }
+
+
+  /* CNI Functions.  */
+
+  //  In the ABI, provided by extern inlines.
+  //  void _Jv_AllocBytes () {}
+  //  void _Jv_AllocString () {}
+  //  void _Jv_AttachCurrentThread () {}
+  //  void _Jv_AttachCurrentThreadAsDaemon () {}
+  //  void _Jv_CreateJavaVM () {}
+  //  void _Jv_DetachCurrentThread () {}
+  void _Jv_Free (void*) {}
+  jsize _Jv_GetStringUTFLength (jstring) { return 0; }
+  jsize _Jv_GetStringUTFRegion (jstring, jsize, jsize, char *) { return 0; }
+  void* _Jv_Malloc (jsize) { return 0; }
+  jstring _Jv_NewString (const jchar*, jsize) { return NULL; }
+  jstring _Jv_NewStringLatin1(const char*, jsize) { return NULL; }
+  jstring _Jv_NewStringUTF (const char *) { return NULL; }
+  void* _Jv_Realloc (void *, jsize) { return NULL; }
+}
+
+/* Classes for primitive types.  */
+
+#define DECLARE_PRIM_TYPE(NAME)			\
+  java::lang::Class _Jv_##NAME##Class __attribute__ ((aligned (8)));
+
+DECLARE_PRIM_TYPE(byte)
+DECLARE_PRIM_TYPE(short)
+DECLARE_PRIM_TYPE(int)
+DECLARE_PRIM_TYPE(long)
+DECLARE_PRIM_TYPE(boolean)
+DECLARE_PRIM_TYPE(char)
+DECLARE_PRIM_TYPE(float)
+DECLARE_PRIM_TYPE(double)
+DECLARE_PRIM_TYPE(void)
Index: gcc/libjava/Makefile.am
===================================================================
--- gcc.orig/libjava/Makefile.am	2009-08-15 01:01:29.000000000 +0100
+++ gcc/libjava/Makefile.am	2009-08-15 01:04:33.128681612 +0100
@@ -358,7 +358,7 @@
 ## Support for libgcj_bc: dummy shared library.
 ##
 ## This lets us have one soname in BC objects and another in C++ ABI objects.
-libgcj_bc_la_SOURCES = libgcj_bc.c
+libgcj_bc_la_SOURCES = libgcj_bc.cc
 libgcj_bc_la_LDFLAGS = -rpath $(toolexeclibdir) -no-static -version-info 1:0:0 \
 	$(LIBGCJ_LD_SYMBOLIC_FUNCTIONS)
 libgcj_bc_la_LIBADD = libgcj.la
Index: gcc/libjava/Makefile.in
===================================================================
--- gcc.orig/libjava/Makefile.in	2009-08-15 01:01:29.000000000 +0100
+++ gcc/libjava/Makefile.in	2009-08-15 01:04:33.128681612 +0100
@@ -1069,7 +1069,7 @@
         -version-info `grep -v '^\#' $(srcdir)/libtool-version` $(LIBGCJ_LD_SYMBOLIC)
 
 lib_gnu_awt_xlib_la_LINK = $(LIBLINK)
-libgcj_bc_la_SOURCES = libgcj_bc.c
+libgcj_bc_la_SOURCES = libgcj_bc.cc
 libgcj_bc_la_LDFLAGS = -rpath $(toolexeclibdir) -no-static -version-info 1:0:0 \
 	$(LIBGCJ_LD_SYMBOLIC_FUNCTIONS)
 

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

[Andrew Haley]

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.

Re: [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.

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

[Nix]

On 15 Aug 2009, Andrew Haley told this:
> BC-compiled executables are being linked against libgcj as well as libgcj_bc.

Um:

spindle 1388 /usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/libjava/testsuite% eu-readelf -a Array_1.exe| grep NEEDED
  NEEDED            Shared library: [libgcj_bc.so.1]
  NEEDED            Shared library: [libc.so.6]

Looks like libgcj_bc.so.1 only to me, and libgcj_bc.so.1 is, as
intended, a nearly-empty wrapper DT_NEEDing libgcj.so.10. ldd looks like:

spindle 1391 /usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/libjava/testsuite% LD_LIBRARY_PATH=.:/usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/./libjava/.libs:/usr/src/gcc/x86_64-spindle/gcc:/usr/src/gcc/x86_64-spindle/gcc/32:/usr/src/gcc/x86_64-spindle/gcc/32/geode:.:/usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/./libjava/.libs:/usr/src/gcc/x86_64-spindle/gcc:/usr/src/gcc/x86_64-spindle/gcc/32:/usr/src/gcc/x86_64-spindle/gcc/32/geode ldd ./Array_1.exe
        linux-vdso.so.1 =>  (0x00007fffa595b000)
        libgcj_bc.so.1 => /usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/libjava/.libs/libgcj_bc.so.1 (0x00007f14c84cf000)
        libc.so.6 => /lib/libc.so.6 (0x00007f14c817d000)
        libgcj.so.10 => /usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/libjava/.libs/libgcj.so.10 (0x00007f14c508e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f14c86d0000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007f14c4e73000)
        librt.so.1 => /lib/librt.so.1 (0x00007f14c4c6b000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f14c4a67000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007f14c4852000)
        libgcc_s.so.1 => /usr/src/gcc/x86_64-spindle/gcc/libgcc_s.so.1 (0x00007f14c463e000)

which looks right to me.

Just teaching my grandfather to suck eggs here for a minute: the problem
is that the reference to the symbol burnt by ld into *Array_1.exe
itself* includes a size, and that size is derived from libgcj_bc.so,
thus is too small:

_Jv_intClass |0000000000601660|GLOBAL|OBJECT  | 4| |.bss

... versus, in libgcj.so.10:

_Jv_intClass |000000000307bcb8|GLOBAL|OBJECT  | 118| prims.cc:824|.bss

It is this mismatch that ld.so is complaining about (during copy
relocation processing, as it happens: see
sysdeps/{x86_64,i386}/dl-machine.h).

It happens to only complain if the reference's size is smaller than the
size of the symbol itself, so we could probably kludge around it by
making the reference in libgcj_bc be to a 64K long array or something
like that. But *that* is even uglier than what I proposed, and if glibc
chooses to become more paranoid (as well it might) then it'll just break
again.

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

[Andrew Haley]

Nix wrote:
> On 15 Aug 2009, Andrew Haley told this:
>> BC-compiled executables are being linked against libgcj as well as libgcj_bc.
> 
> Um:
> 
> spindle 1388 /usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/libjava/testsuite% eu-readelf -a Array_1.exe| grep NEEDED
>   NEEDED            Shared library: [libgcj_bc.so.1]
>   NEEDED            Shared library: [libc.so.6]
> 
> Looks like libgcj_bc.so.1 only to me, and libgcj_bc.so.1 is, as
> intended, a nearly-empty wrapper DT_NEEDing libgcj.so.10. ldd looks like:
> 
> spindle 1391 /usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/libjava/testsuite% LD_LIBRARY_PATH=.:/usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/./libjava/.libs:/usr/src/gcc/x86_64-spindle/gcc:/usr/src/gcc/x86_64-spindle/gcc/32:/usr/src/gcc/x86_64-spindle/gcc/32/geode:.:/usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/./libjava/.libs:/usr/src/gcc/x86_64-spindle/gcc:/usr/src/gcc/x86_64-spindle/gcc/32:/usr/src/gcc/x86_64-spindle/gcc/32/geode ldd ./Array_1.exe
>         linux-vdso.so.1 =>  (0x00007fffa595b000)
>         libgcj_bc.so.1 => /usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/libjava/.libs/libgcj_bc.so.1 (0x00007f14c84cf000)
>         libc.so.6 => /lib/libc.so.6 (0x00007f14c817d000)
>         libgcj.so.10 => /usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/libjava/.libs/libgcj.so.10 (0x00007f14c508e000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007f14c86d0000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x00007f14c4e73000)
>         librt.so.1 => /lib/librt.so.1 (0x00007f14c4c6b000)
>         libdl.so.2 => /lib/libdl.so.2 (0x00007f14c4a67000)
>         libz.so.1 => /usr/lib/libz.so.1 (0x00007f14c4852000)
>         libgcc_s.so.1 => /usr/src/gcc/x86_64-spindle/gcc/libgcc_s.so.1 (0x00007f14c463e000)
> 
> which looks right to me.
> 
> Just teaching my grandfather to suck eggs here for a minute: the problem
> is that the reference to the symbol burnt by ld into *Array_1.exe
> itself* includes a size, and that size is derived from libgcj_bc.so,
> thus is too small:
> 
> _Jv_intClass |0000000000601660|GLOBAL|OBJECT  | 4| |.bss
> 
> ... versus, in libgcj.so.10:
> 
> _Jv_intClass |000000000307bcb8|GLOBAL|OBJECT  | 118| prims.cc:824|.bss
> 
> It is this mismatch that ld.so is complaining about (during copy
> relocation processing, as it happens: see
> sysdeps/{x86_64,i386}/dl-machine.h).
> 
> It happens to only complain if the reference's size is smaller than the
> size of the symbol itself, so we could probably kludge around it by
> making the reference in libgcj_bc be to a 64K long array or something
> like that. But *that* is even uglier than what I proposed, and if glibc
> chooses to become more paranoid (as well it might) then it'll just break
> again.

It's weirder than that.

The problem is due to copy relocs, which are not really compatible with
the BC abi.

On my system, libgcj_bc is linked against libgcj, and the _Jv_intClass in
its .bss is unified with the _Jv_intClass in libgcj.

If you generate a linker map when linking libgcj_bc you should see

Allocating common symbols
Common symbol       size              file

_Jv_doubleClass     0x118             ./.libs/libgcj.so
_Jv_floatClass      0x118             ./.libs/libgcj.so
_Jv_byteClass       0x118             ./.libs/libgcj.so
_Jv_shortClass      0x118             ./.libs/libgcj.so
_Jv_voidClass       0x118             ./.libs/libgcj.so
_Jv_intClass        0x118             ./.libs/libgcj.so
... etc

So, I get
 $ nm --demangle -f sysv .libs/libgcj_bc.so|grep intClass
_Jv_intClass        |0000000000202860|   B  |            OBJECT|0000000000000118|     |.bss

The question, then, is why the linker on your system doesn't unify these .bss symbols.
I think this may be a bug in the linker you're using.

I did the experiment of removing the -lgcj from the link of libgcj_bc: IMO this
link against libgcj shouldn't be done.  And, I got exactly the same failure that
you did:

.../Array_1.exe: Symbol `_Jv_intClass' has different size in shared object, consider re-linking
Aborted

Compiling Array_1 as position-independent code fixes it:

 $ /home/aph/gcc/trunk/obj-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/libjava/testsuite/Array_1.exe
true
false
true
class java.lang.Object
happy:libjava $ nm --demangle -f sysv testsuite/Array_1.exe | grep intClass
_Jv_intClass        |                |   U  |            OBJECT|                |     |*UND*

I think the right fix is to cause BC-compiled executables to be compiled PIC.
The worry I have with that is that there might be some platforms which can
work with BC-compiled code in some way but barf if the compiler sees =-fPIC".

something like

Index: libjava/libgcj.spec.in
===================================================================
--- libjava/libgcj.spec.in	(revision 150702)
+++ libjava/libgcj.spec.in	(working copy)
@@ -9,4 +9,4 @@
 %rename lib liborig
 *lib: @LD_START_STATIC_SPEC@ @LIBGCJ_SPEC@ @LD_FINISH_STATIC_SPEC@ -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ %(libgcc) @LIBSTDCXXSPEC@ %(liborig)

-*jc1: @HASH_SYNC_SPEC@ @DIVIDESPEC@ @CHECKREFSPEC@ @JC1GCSPEC@ @EXCEPTIONSPEC@ @BACKTRACESPEC@ @IEEESPEC@ @ATOMICSPEC@ -fkeep-inline-functions
+*jc1: @HASH_SYNC_SPEC@ @DIVIDESPEC@ @CHECKREFSPEC@ @JC1GCSPEC@ @EXCEPTIONSPEC@ @BACKTRACESPEC@ @IEEESPEC@ @ATOMICSPEC@ -fkeep-inline-functions %{findirect-dispatch:-fPIC}
Index: libjava/Makefile.am
===================================================================
--- libjava/Makefile.am	(revision 150701)
+++ libjava/Makefile.am	(working copy)
@@ -361,8 +361,8 @@
 libgcj_bc_la_SOURCES = libgcj_bc.c
 libgcj_bc_la_LDFLAGS = -rpath $(toolexeclibdir) -no-static -version-info 1:0:0 \
 	$(LIBGCJ_LD_SYMBOLIC_FUNCTIONS)
-libgcj_bc_la_LIBADD = libgcj.la
-libgcj_bc_la_DEPENDENCIES = libgcj.la
+libgcj_bc_la_LIBADD =
+libgcj_bc_la_DEPENDENCIES =
 libgcj_bc_la_LINK = $(LIBLINK)
 ## This is specific to Linux/{Free,Net,Open}BSD/Hurd and perhaps few others.
 ## USE_LIBGCJ_BC shouldn't be set on other targets.

I'll have a look at using autoconf to check for "-fPIC" when compiling an
executable.

Andrew.

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

[Andrew Haley]

This is what I went with.  On all systems which can use libgcj_bc,
Linux/{Free,Net,Open}BSD/Hurd and perhaps few others, USE_LIBGCJ_BC
is set.  In that case, we add

  %{findirect-dispatch:-fPIC}

to libgcj.spec, which causes all BC-compiled programs to be linked PIC.
PIC-compiled executables don't have copy relocs and do not depend on
symbols like _Jv_intClass having any particular size.

Please let me know if this works for you.

Andrew.


2009-08-17  Andrew Haley  <aph@redhat.com>

	* Makefile.am (libgcj_bc_la_LIBADD): Delete.
	* libgcj.spec.in: (LIBGCJ_BC_SPEC): New spec.
	* configure.ac (LIBGCJ_BC_SPEC): New spec.


Index: configure.ac
===================================================================
--- configure.ac	(revision 150834)
+++ configure.ac	(working copy)
@@ -1078,8 +1078,10 @@
 LIBGCJ_SPEC="%{s-bc-abi:} -lgcj"
 if test "$use_libgcj_bc" = yes; then
   LIBGCJ_SPEC="%{static|static-libgcj|!s-bc-abi:-lgcj;:-lgcj_bc}"
+  LIBGCJ_BC_SPEC="%{findirect-dispatch:-fPIC}"
 fi
 AC_SUBST(LIBGCJ_SPEC)
+AC_SUBST(LIBGCJ_BC_SPEC)

 HASH_SYNC_SPEC=
 # Hash synchronization is only useful with posix threads right now.
Index: libgcj.spec.in
===================================================================
--- libgcj.spec.in	(revision 150834)
+++ libgcj.spec.in	(working copy)
@@ -9,4 +9,4 @@
 %rename lib liborig
 *lib: @LD_START_STATIC_SPEC@ @LIBGCJ_SPEC@ @LD_FINISH_STATIC_SPEC@ -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ %(libgcc) @LIBSTDCXXSPEC@ %(liborig)

-*jc1: @HASH_SYNC_SPEC@ @DIVIDESPEC@ @CHECKREFSPEC@ @JC1GCSPEC@ @EXCEPTIONSPEC@ @BACKTRACESPEC@ @IEEESPEC@ @ATOMICSPEC@ -fkeep-inline-functions
+*jc1: @HASH_SYNC_SPEC@ @DIVIDESPEC@ @CHECKREFSPEC@ @JC1GCSPEC@ @EXCEPTIONSPEC@ @BACKTRACESPEC@ @IEEESPEC@ @ATOMICSPEC@ @LIBGCJ_BC_SPEC@ -fkeep-inline-functions
Index: Makefile.am
===================================================================
--- Makefile.am	(revision 150834)
+++ Makefile.am	(working copy)
@@ -358,10 +358,10 @@
 ## Support for libgcj_bc: dummy shared library.
 ##
 ## This lets us have one soname in BC objects and another in C++ ABI objects.
+## This library is not linked against libgcj.
 libgcj_bc_la_SOURCES = libgcj_bc.c
 libgcj_bc_la_LDFLAGS = -rpath $(toolexeclibdir) -no-static -version-info 1:0:0 \
 	$(LIBGCJ_LD_SYMBOLIC_FUNCTIONS)
-libgcj_bc_la_LIBADD = libgcj.la
 libgcj_bc_la_DEPENDENCIES = libgcj.la
 libgcj_bc_la_LINK = $(LIBLINK)
 ## This is specific to Linux/{Free,Net,Open}BSD/Hurd and perhaps few others.

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

[Nix]

On 17 Aug 2009, Andrew Haley spake thusly:
> Please let me know if this works for you.

Doesn't apply against 4.4-branch, but the fix is trivial (no
@ATOMICSPEC@ in libgcj.spec.in), so I did that.

Unfortunately you touched configure.ac and Makefile.am both, and I hit a
wall trying to convince autoreconf to play along. GCC is famously picky
about the exact versions of the autotools in use, so I installed
automake-1.9.6 and autoconf-2.59 (libtool was fine), which were used to
generate the stuff in libjava/, but then got this:

spindle 564 /usr/src/gcc/gcc/libjava% AUTOCONF=autoconf-2.59 AUTOHEADER=autoheader-2.59 AUTOMAKE=automake-1.9 autoreconf-2.59 -fiv
autoreconf-2.59: Entering directory `.'
autoreconf-2.59: configure.ac: not using Gettext
autoreconf-2.59: running: aclocal --force -I . -I .. -I ../config -I libltdl
libltdl/acinclude.m4:6188: the serial number must appear before any macro definition
../config/override.m4:24: error: m4_copy: won't overwrite defined macro: AC_PREREQ
../config/override.m4:24: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: autom4te failed with exit status: 1
autoreconf-2.59: aclocal failed with exit status: 1

(I tried at the top level too: same result.)

I do not claim to be clueless at autoconfery, but this error has me
stumped. What magic invocation do I need to regenerate these things?
This error isn't happening at the macro that's supposed to prevent
regeneration with th ewrong autoconf version, but at the one above it...

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

[Andrew Haley]

Nix wrote:
> On 17 Aug 2009, Andrew Haley spake thusly:
>> Please let me know if this works for you.
> 
> Doesn't apply against 4.4-branch, but the fix is trivial (no
> @ATOMICSPEC@ in libgcj.spec.in), so I did that.
> 
> Unfortunately you touched configure.ac and Makefile.am both, and I hit a
> wall trying to convince autoreconf to play along. GCC is famously picky
> about the exact versions of the autotools in use, so I installed
> automake-1.9.6 and autoconf-2.59 (libtool was fine), which were used to
> generate the stuff in libjava/, but then got this:
> 
> spindle 564 /usr/src/gcc/gcc/libjava% AUTOCONF=autoconf-2.59 AUTOHEADER=autoheader-2.59 AUTOMAKE=automake-1.9 autoreconf-2.59 -fiv
> autoreconf-2.59: Entering directory `.'
> autoreconf-2.59: configure.ac: not using Gettext
> autoreconf-2.59: running: aclocal --force -I . -I .. -I ../config -I libltdl
> libltdl/acinclude.m4:6188: the serial number must appear before any macro definition
> ../config/override.m4:24: error: m4_copy: won't overwrite defined macro: AC_PREREQ
> ../config/override.m4:24: the top level
> autom4te: /usr/bin/m4 failed with exit status: 1
> aclocal: autom4te failed with exit status: 1
> autoreconf-2.59: aclocal failed with exit status: 1
> 
> (I tried at the top level too: same result.)
> 
> I do not claim to be clueless at autoconfery, but this error has me
> stumped. What magic invocation do I need to regenerate these things?
> This error isn't happening at the macro that's supposed to prevent
> regeneration with th ewrong autoconf version, but at the one above it...

In my experience the only thing that works is to add autoconf and
automake to the head of your PATH and invoke them as "autoconf" and
"automake".

Andrew.

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

[Nix]

On 18 Aug 2009, Andrew Haley outgrape:
> Nix wrote:
>> libltdl/acinclude.m4:6188: the serial number must appear before any macro definition
>> ../config/override.m4:24: error: m4_copy: won't overwrite defined macro: AC_PREREQ
>> ../config/override.m4:24: the top level
>> autom4te: /usr/bin/m4 failed with exit status: 1
>> aclocal: autom4te failed with exit status: 1
>> autoreconf-2.59: aclocal failed with exit status: 1
>> 
>> (I tried at the top level too: same result.)
>> 
>> I do not claim to be clueless at autoconfery, but this error has me
>> stumped. What magic invocation do I need to regenerate these things?

strace tracked it down: automake-1.9 was internally executing
'/usr/bin/autom4te', not autom4te with the appropriate program-prefix/
suffix/transform applied. I'd submit a patch but this version of
automake is long dead.

Anyway, with that fixed, your patch seems to work: the libjava testsuite
passes:

WARNING: Couldn't find the global config file.
Test Run By compiler on Tue Aug 18 20:22:38 2009
Native configuration is x86_64-pc-linux-gnu

                === libjava tests ===

Schedule of variations:
    unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /usr/src/gcc/4.4-090813/libjava/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /usr/src/gcc/4.4-090813/libjava/testsuite/libjava.cni/cni.exp ...
Running /usr/src/gcc/4.4-090813/libjava/testsuite/libjava.jar/jar.exp ...
Running /usr/src/gcc/4.4-090813/libjava/testsuite/libjava.jni/jni.exp ...
Running /usr/src/gcc/4.4-090813/libjava/testsuite/libjava.jvmti/jvmti-interp.exp ...
LD_LIBRARY_PATH=. /usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/./libjava/gij -cp /usr/src/gcc/4.4-090813/libjava/testsuite/libjava.jvmti/interp/getargssize.jar -agentlib:dummyagent getargssize
LD_LIBRARY_PATH=. /usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/./libjava/gij -cp /usr/src/gcc/4.4-090813/libjava/testsuite/libjava.jvmti/interp/getlocalvartable.jar -agentlib:dummyagent getlocalvartable
LD_LIBRARY_PATH=. /usr/src/gcc/x86_64-spindle/x86_64-pc-linux-gnu/./libjava/gij -cp /usr/src/gcc/4.4-090813/libjava/testsuite/libjava.jvmti/interp/getstacktrace.jar -agentlib:dummyagent getstacktrace
Running /usr/src/gcc/4.4-090813/libjava/testsuite/libjava.jvmti/jvmti.exp ...
Running /usr/src/gcc/4.4-090813/libjava/testsuite/libjava.lang/lang.exp ...
Running /usr/src/gcc/4.4-090813/libjava/testsuite/libjava.loader/loader.exp ...
Running /usr/src/gcc/4.4-090813/libjava/testsuite/libjava.mauve/mauve.exp ...
Running /usr/src/gcc/4.4-090813/libjava/testsuite/libjava.special/special.exp ...
Running /usr/src/gcc/4.4-090813/libjava/testsuite/libjava.verify/verify.exp ...

                === libjava Summary ===

# of expected passes            2582