[Gc] RE: libgcj missing symbol __data_start
hans.boehm at hp.com
Wed Aug 26 10:41:33 PDT 2009
[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
> 80: 0000000000000000 0 NOTYPE WEAK DEFAULT UND
> 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;
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.
More information about the Gc