Problems with shared library (-fPIC) and tango

e-t172 e-t172 at akegroup.org
Wed Dec 3 11:07:20 PST 2008


Thomas Leonard wrote:
> 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.

Sorry for the ten days delay, I was very busy lately.

When I did some tests compiling Tango as a shared library, I noticed 
that all D static constructors present in the shared library were being 
called, which was kind of annoying at the time (for example, I got 
messages about "tina initialization" for a simple Hello world...).

-- 
Etienne Dechamps / e-t172 - AKE Group

Website: http://www.e-t172.net/
Contact: e-t172 at akegroup.org

Phone: +33547414942
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2639 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20081203/9d03c25e/attachment.bin>


More information about the Digitalmars-d mailing list