Re: [Caml-list] PIC

[Xavier Leroy <Xavier.Leroy@inria.fr>]

> 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