I think we may attach different meanings to "position independent code."
For me PIC includes PIC suitable for dynamic linking. (This is what the
-fPIC option tells GCC to do.)

-- Alexander

-----Original Message-----
From: skaller [mailto:skaller@users.sourceforge.net] 
Sent: Wednesday, October 05, 2005 4:15 AM
To: Alexander Bottema
Cc: caml-list@yquem.inria.fr
Subject: RE: [Caml-list] Dynamic linking

On Tue, 2005-10-04 at 11:56 -0400, Alexander Bottema wrote:
> But the problem with a DLL is that you never now what address will be
> allocated for your executable. It can be located anywhere between 0
and
> 2^64-1. 

Not on current versions of Linux/x86_64. They only support 48 bit
code addresses (I think it is 48 bits), this is the so-called
'small model'.

> Thus, when a DLL calls another DLL a 64-bit call is potentially
> required. AMD64 supports global address tables that enable you to
> translate a 32-bit call into a 64-bit one (likewise with data access).
> If you compile a C file with gcc (-fPIC -S) you'll get code that looks
> like this:

I know ..but it has NOTHING to do with position independent code.

> For OCaml to work you need to emit instructions of type 'call foo@PLT'
> and 'movl xyzzy@GOT(%ebx)'. Currently, the OCaml does not do this for
> AMD64, which is the heart of the problem. If you think this is trivial
> to fix, please go head and do it; I'd be very happy.

This has nothing to do with making the *code* position independent.
It is to do with supporting elf/ld.so dynamic loading. This is
another issue entirely. 

Clearly, to access a symbol of an 'unknown' address,
you put the address into a known table slot instead,
when the library is loaded, and access indirectly.

In any case, this doesn't solve the problem, but it does
identify it correctly: the problem is to emit instructions
to bind to load-time linked libraries on Linux/Elf/ld.so 
platforms. You can be sure Windows -- for the same processor --
uses a different dynamic linkage model .. :)


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