Re: Problems with shared library (-fPIC) and tango

[e-t172]

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 ([EMAIL PROTECTED])'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.

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

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): 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.



--
Etienne Dechamps / e-t172 - AKE Group

Website: http://www.e-t172.net/
Contact: [EMAIL PROTECTED]

Phone: +33547414942

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...).

smime.p7s
Description: S/MIME Cryptographic Signature