Problems with shared library (-fPIC) and tango

[Thomas Leonard]

On Thu, 23 Oct 2008 19:59:30 -0700, Sean Kelly wrote:
> Thomas Leonard wrote:
>> On Sun, 06 Jul 2008 03:31:44 +0000, Sean Kelly wrote:
>>> == Quote from e-t172 (e-t172 at akegroup.org)'s article
>>>> IIRC, there is only one problem when trying to build Tango with -fPIC
>>>> : the garbage collector, which segfaults on collection. Fix the GC
>>>> and you have your Tango shared library.
>>> I believe this is an issue with the static data segments not being
>>> represented in the way that the GC expects in a shared library.  I
>>> really need to do some research to figure out how things are different
>>> in this instance.  Though if someone knows then that would be good too
>>> :-)
>> 
>> Could that be why this program crashes?
>> 
>> import std.gc: fullCollect;
>> import mi = std.moduleinit;
>> 
>> int main(string[] args) {
>> 	//printf("%p\n", mi._moduleinfo_dtors[6]); fullCollect();
>> 
>> 	return 0;
>> }
>> 
>> If I uncomment the printf line, it works (I guess because the address
>> gets left on the stack). Without calling fullCollect() explicitly, my
>> programs work until the GC gets called, then they crash.
>> 
>> I'm using a (rather modified) GDC on Linux, with libgphobos2 as a
>> shared library.
>> 
>> How are module variables like _moduleinfo_dtors supposed to get
>> registered as roots with the GC?
> 
> The shared data segment(s) of a binary are identified by the runtime at
> startup and the runtime passes them to the GC for scanning.  For
> example, look at initStaticDataPtrs() in this file:
> 
> http://dsource.org/projects/tango/browser/trunk/lib/compiler/gdc/
memory.d
> 
> However, I think the way that the static data segment is identified in a
> shared library is different from in an executable app.  I'm pretty sure
> the Boehm GC handles this properly and have been meaning to look at it
> for clues, but that hasn't made it to the top of my priority list yet.

Ah, thanks for the hints. I found some disabled code in gcgcc.d that 
tried to scan /proc/self/maps, and with a bit of tweaking it now works 
for me (tested on x86_64):

http://repo.or.cz/w/delight/core.git?
a=commitdiff;h=83befaa3f72973eb8afd8589d2e1cee4b37ee4fb;hp=03f581cf37409b35521bcfd6f239a14f1fa73221

BTW, would it be possible to get rid of this moduleinfo stuff? It seems 
to cause a lot of problems, because when a program imports a library it 
might not use exactly the same flags that were used when the library was 
compiled (e.g. program is compiled with unit-tests, library wasn't). So 
the program might try to use the moduleinfo, even though it doesn't 
actually exist.

Doesn't the dynamic linker already provide for calling static 
initialisers? I'm not sure.