English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-12-27 (12:23)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] PIC
On Tue, 2005-12-27 at 11:03 +0100, Xavier Leroy wrote:
> > I notice Ocaml 3.09 has -fPIC option. Thanks! This is a step
> > towards dynamic loading in native code.

Thanks for your summary!

> Encapsulation of compiled OCaml code as a shared library that can be
> called from C is possible, on x86 at least.


> This is a very good approach to use OCaml code from other languages
> (e.g. Java) or as plug-ins (e.g. in Apache).

Indeed! If I understand correctly, this requires redistribution
of "LGPL with Linking Exception" parts of Ocaml only?

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

I suspect you're being polite .. 'broken' seems to the
correct term ;( The same techniques should work for the
x86_64 as the x86 .. just making sure 64 bit values are
supported (by the loader and ELF formats) should be enough.

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

I see. Ok, thanks for that info. Having looked into this
myself .. I'm not surprised ..  Sigh. Is the ia64 any better?

> Dynamic loading of OCaml code from OCaml code raises many other
> issues. 

Type safety, version compatibility, etc being a few.
But one can work around this problem, perhaps messily and
riskily, if the codes can be loaded and connected together
with C glue.

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

Yes, thanks. I hope I covered the combinations reasonably
well, so your responses are fairly clear summary of the
situation, which is what I was looking for: thanks!

John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net