Problems with shared library (-fPIC) and tango

Thomas Leonard talex5+d at gmail.com
Fri Oct 24 12:47:14 PDT 2008


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.



More information about the Digitalmars-d mailing list