Re: libgcj missing symbol __data_start

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  <[email protected]>

	* 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};