From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 405E4BB81 for ; Tue, 27 Dec 2005 11:03:26 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jBRA3P5F000612 for ; Tue, 27 Dec 2005 11:03:25 +0100 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 LAA23017 for ; Tue, 27 Dec 2005 11:03:25 +0100 (MET) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id jBRA3PZh006283 for ; Tue, 27 Dec 2005 11:03:25 +0100 Received: from [192.168.1.2] (che78-2-82-237-71-191.fbx.proxad.net [82.237.71.191]) by smtp4-g19.free.fr (Postfix) with ESMTP id C1BF44EC2F; Tue, 27 Dec 2005 11:03:24 +0100 (CET) Message-ID: <43B1116C.5060407@inria.fr> Date: Tue, 27 Dec 2005 11:03:24 +0100 From: Xavier Leroy User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: skaller Cc: caml-list@inria.fr Subject: Re: [Caml-list] PIC References: <1135476423.28426.45.camel@rosella> In-Reply-To: <1135476423.28426.45.camel@rosella> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 43B1116D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 43B1116D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 3.09:01 -fpic:01 ocaml:01 ocamlc:01 -output-obj:01 ocamlopt:01 -output-obj:01 gcc:01 -shared:01 stub:01 run-time:01 plug-ins:01 -fpic:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 > I notice Ocaml 3.09 has -fPIC option. Thanks! This is a step > towards dynamic loading in native code. > > I wonder, is it actually supported -- or even possible > to load native code (on suitable platforms) at startup > from C? From an Ocaml mainline? > > What's left to be able to 'dlopen()' a function library? > From C? From Ocaml? Will that ever be possible? Encapsulation of compiled OCaml code as a shared library that can be called from C is possible, on x86 at least. The procedure is similar to that described in section 18.8 of the reference manual, namely, use "ocamlc -output-obj" or "ocamlopt -output-obj" to package the Caml code as a .o file, then use "gcc -shared" (or equivalent commands to build shared objects) to group together this .o file, the C stub code that calls back into OCaml, and the OCaml run-time system. This is a very good approach to use OCaml code from other languages (e.g. Java) or as plug-ins (e.g. in Apache). The reason it works particularly well for x86 is that dynamic loaders for x86 (both under Unix/Linux and Windows) can relocate arbitrary code, not necessarily PIC code. This is unfortunately not the case for all target architectures. In particular, dynamic loaders for x86_64 (AMD64) are much less forgiving. The -fPIC option to ocamlopt you mention was added to the AMD64 code generator in an attempt to generate "more position-independent" code. However, it does not quite work yet. A difficulty is the paucity of documentation on what, exactly, the Linux AMD64 dynamic loader can relocate. Dynamic loading of OCaml code from OCaml code raises many other issues. It is currently supported for bytecode only, and will not be available for native code in the forseeable future. I have already discussed this on this list earlier. > [Another question, whether one can wrap native code > so it can be called from bytecode.. this would allow > bytecode programs to generate and compile bytecode > extensions .. without the bulk of the code running > slowly] Again, I believe this has been discussed at length before. The short answer is: no. A longer answer is the asmdynlink library by Fabrice Le Fessant, which (used to) enable this kind of things with some speed penalty on the interpretation of the bytecode. - Xavier Leroy