libgcj missing symbol __data_start
Andrew Haley
aph@redhat.com
Tue Sep 1 15:33:00 GMT 2009
Andreas Krebbel wrote:
> Hi Andrew,
>> I see a lot of libjava fails on s390 when the -findirect-dispatch
> switch is used. The testcases fail with:
>> /gcc-build/s390x-ibm-linux-gnu/libjava/testsuite/anonarray.exe: symbol
> lookup error:
> /gcc-build/s390x-ibm-linux-gnu/libjava/.libs/libgcj.so.11: undefined
> symbol: __data_start
>> This symbol used to be in the .dynsym section of the main executable
> after linking. I think it was exported since libgcj.so requires
> it. But with your change libgcj_bc.so does not depend on libgcj.so
> anymore and since the link step does not directly use libgcj.so it is
> not loaded while linking the main executable
That's the idea, yes.
> what seems to lead to the
> __data_start symbol to be ommitted from the .dynsym section.
>> rev 150852:
> ldd libgcj_bc.so
> libc.so.6 => /lib64/libc.so.6 (0x0000020000020000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000020000182000)
> /lib/ld64.so.1 (0x000002aaaaaaa000)
>> rev 150853:
> ldd libgcj_bc.so
> libgcj.so.11 => /home/krebbel/build/gcc-build/s390x-ibm-linux-gnu/libjava/.libs/libgcj.so.11 (0x0000020000005000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00000200033bc000)
> librt.so.1 => /lib64/librt.so.1 (0x00000200033d7000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00000200033e2000)
> libz.so.1 => /lib64/libz.so.1 (0x00000200033e7000)
> libc.so.6 => /lib64/libc.so.6 (0x00000200033ff000)
> libgcc_s.so.1 => /home/krebbel/build/gcc-install/lib/../lib64/libgcc_s.so.1 (0x0000020003562000)
> /lib/ld64.so.1 (0x000002aaaaaaa000)
>> Does that make sense to you? Could you please have a look if so?
I can make no sense of this at all. When I build a simple executable,
before and after my patch, I get:
happy:~ $ /home/aph/gcc/trunk/install/bin/gcj Hello.java --main=Hello -Wl,-Map,map -findirect-dispatch
happy:~ $ readelf -D -s a.out | grep __data_start
2 2: 00000000006013e0 0 NOTYPE GLOBAL DEFAULT 24 __data_start
Looking in the linker map, I see
.data 0x00000000006013e0 0x198
*(.data .data.* .gnu.linkonce.d.*)
.data 0x00000000006013e0 0x4 /usr/lib/../lib64/crt1.o
0x00000000006013e0 __data_start
0x00000000006013e0 data_start
So, someone is using __data_start, but I don't know who.
Please try this.
Andrew.
2009年09月01日 Andrew Haley <aph@redhat.com>
* libgcj_bc.c (__data_start, data_start, _end): Add dummy usage.
Index: libgcj_bc.c
===================================================================
--- libgcj_bc.c (revision 150834)
+++ libgcj_bc.c (working copy)
@@ -112,3 +112,14 @@
DECLARE_PRIM_TYPE(float)
DECLARE_PRIM_TYPE(double)
DECLARE_PRIM_TYPE(void)
+
+
+/* Force executable to export __data_start et al. */
+
+#pragma weak __data_start
+extern int __data_start[];
+#pragma weak data_start
+extern int data_start[];
+#pragma weak _end
+extern int _end[];
+static void *dummy[] __attribute__((used)) = {__data_start, data_start, _end};
More information about the Java
mailing list