From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id BAA30431; Sat, 8 Dec 2001 01:56:20 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA30406 for ; Sat, 8 Dec 2001 01:56:17 +0100 (MET) Received: from comtv.ru (mail.comtv.ru [217.10.32.4]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id fB80uF507161; Sat, 8 Dec 2001 01:56:15 +0100 (MET) Received: from [10.2.64.72] (HELO oyster2) by comtv.ru (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1567473; Sat, 08 Dec 2001 03:56:14 +0300 Date: Sat, 8 Dec 2001 03:53:18 +0300 (MSK) From: malc X-Sender: malc@oyster To: Xavier Leroy cc: Vitaly Lugovsky , caml-list@inria.fr Subject: Re: [Caml-list] -ccopt -shared In-Reply-To: <20011207222330.A26382@pauillac.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 7 Dec 2001, Xavier Leroy wrote: > > > If you really want to create a shared library containing OCaml code > > > and the OCaml runtime system, this can be done, but you need to use > > > ocamlc -output-obj or ocamlopt -output-obj to package the OCaml code > > > as a C object. > > > > And the resulting code will be PIC on x86 with a native compiler? > > No. It will not be position-independent code. But good dynamic > linkers such as those of Linux and Windows do not require > position-independent code; they can also load dynamically code > containing absolute references. This is a bit slower than dynamically > linking pure PIC code, and prevents the sharing of the code segment > between several processes that load the shared library, but it still works. > Yes sharability is lost, and loading time should be worse (lots of stuff to fix), the runtime speed however will be better. I have investigated PICability of OCaml generated code (which is really a nobrainer to implement on i386), and came to the conclusion that its not worth it. OCaml uses much more absolute references than any C application. Loosing ebx permanently, one other general register per memory reference, adding prologue to every function(one can get around that but erm...) and appending @PLT to every function call will have significant penalty on OCaml native backend generated code speed. Then there is COPY_RELOC problem, only SUN's and CVS binutils ld can omit generation of this type of relocation. And one more thing about sharability(which is the one and only argument in favor of PIC) Windows never had it, and seems like no one is complaining. They say Alpha doesnt have PIC either (will be interesting to know why) > > Is it already usefull? > > Depends what you need shared libraries for. If your goal is to reduce > memory consumption because many running processes share the library, > then no, it's not useful. But it *is* useful if your goal is to > interface with another system that cannot statically link with your > code and absolutely requires foreign code to be a shared library, such > as Java's native method interface, or COM's "in-proc" components. > > - Xavier Leroy -- mailto:malc@pulsesoft.com ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr