This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: libgcj missing symbol __data_start
- From: "Boehm, Hans" <hans dot boehm at hp dot com>
- To: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, Andrew Haley <aph at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "java at gcc dot gnu dot org" <java at gcc dot gnu dot org>, "gc at linux dot hpl dot hp dot com" <gc at linux dot hpl dot hp dot com>
- Date: Wed, 26 Aug 2009 17:41:33 +0000
- Subject: RE: libgcj missing symbol __data_start
- References: <20090825142045.GA14401@bart> <4A941494.8060107@redhat.com> <4A9563A7.4000209@linux.vnet.ibm.com>
[Adding the gc mailing list, since this still applies to current gc versions.]
> -----Original Message-----
> From: Andreas Krebbel
> Sent: Wednesday, August 26, 2009 9:33 AM
>
> > Hard to say; I have no idea why s/390 should be any
> different from any
> > of the other systems. We have a s/390 here at Red Hat but
> it might be
> > easier if there's a way I could log onto your system and
> have a look.
> No. It is unfortunately impossible to give you access to one
> of our systems for various reasons. But I tried to track it down:
>
> On x86_64 the __data_start is declared weak:
> [boehm-gc]$ readelf -s .libs/libgcjgc_convenience.a | grep
> __data_start
> 80: 0000000000000000 0 NOTYPE WEAK DEFAULT UND
> __data_start
>
> On s390x the symbol is declared global. The difference seem
> to come from boehm-gc/include/private/gcconfig.h which uses
> pragma weak for x86 but not for S/390.
>
> Since the symbol is weak on x86 the __data_start symbol
> missing in the main executable does not lead to an error.
>
> The following patch fixes all the failures on s390x. But I'm
> not sure if that's the right thing to do:
>
> Index: boehm-gc/include/private/gcconfig.h
> ===================================================================
> *** boehm-gc/include/private/gcconfig.h.orig 2008-12-02
> 14:08:42.000000000 +0100
> --- boehm-gc/include/private/gcconfig.h 2009-08-26
> 17:07:12.000000000 +0200
> ***************
> *** 1826,1831 ****
> --- 1826,1832 ----
> # define OS_TYPE "LINUX"
> # define LINUX_STACKBOTTOM
> # define DYNAMIC_LOADING
> + # pragma weak __data_start
> extern int __data_start[];
> # define DATASTART ((ptr_t)(__data_start))
> extern int _end[];
>
>
> Bye,
>
> -Andreas-
>
Unfortunately, I don't think this is the right solution. If I understand correctly, DATASTART will end up as zero, which will cause the collector to start tracing at location zero, which seems unlikely to work, if the value is needed. I suspect the value isn't actually used when dl_iterate_phdr is available and the application is dynamically linked, but still ...
Another popular option on other architectures is to define SEARCH_FOR_DATA_START instead of defining DATASTART to have a specific value. This creates a weak reference to __data_start. If that ends up being zero, the collector will walk the address space backwards starting at __end until an access faults. It will assume that that's the beginning of the main data segment. That might make debugging a bit harder because of the extra SIGSEGV at startup, but I still think it's a much better solution, assuming it actually works. If it doesn't, this at least needs a conspicuous FIXME comment, since it's pretty clearly doing the wrong thing. In any case, I think this should also go in the upstream source.
Hans