Problems with shared library (-fPIC) and tango

[Sean Kelly]

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
>>> Lars Ivar Igesund a écrit :
>>>> There is a ticket related to this somewhere. I believe I was told
>>>> once that part of the problem is that _all_ of the runtime can't be
>>>> part of the dynamic library, but that there needs to be a static
>>>> portion too with at least main. The above issue may have more to do
>>>> with the effect of PIC on the code though. It would be very good if
>>>> it could be resolved.
>>> 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.


Sean