RE: libgcj missing symbol __data_start

[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