From owner-freebsd-hackers Thu Apr 24 09:39:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA15686 for hackers-outgoing; Thu, 24 Apr 1997 09:39:16 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA15681 for ; Thu, 24 Apr 1997 09:39:13 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA01357; Thu, 24 Apr 1997 09:34:12 -0700 From: Terry Lambert Message-Id: <199704241634.JAA01357@phaeton.artisoft.com> Subject: Re: Dynamic linking libraries [Q] To: rssh@cki.ipri.kiev.ua Date: Thu, 24 Apr 1997 09:34:12 -0700 (MST) Cc: terry@lambert.org, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG In-Reply-To: <335F299C.843@cki.ipri.kiev.ua> from "Ruslan Shevchenko" at Apr 24, 97 12:36:22 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > No it's not. It's at 20ec, in the image -- and is in the data segment > > of the in core image. You are dereferencing the thing. > > > > The compiler can not generate a post-link reference to the data in > > a shared library unless it knows where the data will be mapped in > > memory. > > > > But we can do pointer to the data, which have p[ost0link reference Yes. That's exactly what sys_errlist[] is: the address of the first element in the array. It's (functionally, and barring ANSI distinctions between x[] and *x) a pointer. A pointer located in the data segment of the program age, but orginating as a data declaration in the library, and moved there on link. > > Are you claiming that the image is "fixed up" for all references? > > If it were, then the idea of "shared code" would go out the window. > > What means fixed-up ? It means that the linker emits a table of entries in an unmapped region of memory and crt0 installs a fault handler, and references to the faulted area have their target addresses rewritten, and the instruction is restarted. Microsoft does this for function call references, but all "fixups" are in the jump table. FreeBSD has to do the same thing. Any code that wants to reference code at an unknown location but with a predesignated set of entry points has to have a jump table. The jump table fixups can be done on image load, but are generally done at reference (this is called "lazy binding" or "late binding"). Because you must implement fault handling for this to work generally, and because the references are data references, there is not vtable reference possible unless the datum is a pointer (and generally, not even then unless your linker is very, very clever). So the fixups take the form of rewriting the code that references the variable. This technique only works with absolute data references. If you load a register with an address 40 instructions before, the instruction must be simulated through the relocation. This is expensive (but was in fact used on 68000 based systems, since the 68000 failed to implement instruction -restart-after-fault correctly. There is an interesting code fragment for the 68010 to handle MPSW faults to make it look like a 68000 that relies on this). In any case, FreeBSD doesn't do this because in order to do so reliably, it would need to have another "unmapped" section in a.out to initiate the fault, and a split SIGFAULT handler that preemptively checked to see if the fault was in this region. Even then, the buffer length relationships would be tied to the shared library version, or there would be no way to tell what data was being referenced at fault time. Actually, this type of relocation is one of the few places segment registers become useful. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.