[MLton] x86_64 port status

[skaller]

On Sun, 2006-05-07 at 22:44 -0500, Henry Cejtin wrote:
> I don't understand what you mean about unresolved symbols being reported only
> at run time.  If I refer to some variable which isn't in the shared library
> being linked against then the linker will complain. 

Sorry, I missed a qualification. Building shared libraries:

--------------------------------------------------------
--allow-shlib-undefined
--no-allow-shlib-undefined
Allows  (the  default)  or  disallows  undefined  symbols in shared
libraries.  This switch is similar to --no-undefined except that it
determines the behaviour when the undefined symbols are in a shared
library rather than a regular object file.  It does not affect  how
undefined symbols in regular object files are handled.

The  reason that --allow-shlib-undefined is the default is that the
                 **************************************
shared library being specified at link time may not be the same  as
the  one that is available at load time, so the symbols might actu‐
ally be resolvable at load time.  Plus there are some systems,  (eg
BeOS)  where undefined symbols in shared libraries is normal.  (The
kernel patches them at load time to select which function  is  most
appropriate for the current architecture.  This is used for example
to dynamically select an appropriate memset function).   Apparently
it  is also normal for HPPA shared libraries to have undefined sym‐
bols.
---------------------------

On x86_64 it is NOT possible to just turn this flag on,
because PLT and whatever global table crud is used
for dynamic libraries are global symbols. The only way to
actually ensure all symbols are linked requires a platform
specific link of the x86_64 loader library.

Note this applies to building shared libraries, not applications.
It happens Felix applications are built as shared libraries,
so I forgot to qualify my claim. Sorry. The result is just
as much a disaster for any language building a library:
there's no way to tell if the library has undefined references
until you run an application that uses it.

This is exceptionally disgusting and a result of the stupid
way dynamic linkage is handled on Linux (at least on x86_64): 
calls to shared library entry points cost many extra instructions. 
[AFAIK on Windows shared libraries have fixed load points, and 
there is no extra penalty. Cygwin provides a utility to handle
this 'rebase' which changes a DLL's load address]

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