Hi Phil,
Thanks for that. I've made some changes and if it all seems to work out
I'll merge it into master. I've added some comments below.
On 05/10/2018 09:23, Phil Clayton wrote:
I'm glad to see that Poly/ML does not include symbols in the object file
that are referenced from ML but not required, e.g. because they occur in
code that is never reached. That's a useful property because it allows
a library of ML bindings to support more functions than actually
provided by the installed version of a binary library and required by
the application. Hopefully it will be possible to keep that property.
External symbols are ML cells that are recognised specially by
PolyML.export and turned into linker symbols. Since PolyML.export only
exports reachable ML data the resulting object file will only contain
symbols that are part of the exported code. A consequence of this is
that if the object file is then linked with a static library version of
the C code the final executable will only contain the C code that is
actually required. An executable created using external symbols and a
statically linked library will generally be more compact than having a
separate dynamic library. It also avoids the need for path
specifications such as LD_LIBRARY_PATH.
I have run into a general issue. After redefining a local version of
the getSymbol function to use externalFunctionSymbol internally, I found
that programs compiled and linked fine but seg faulted before entering
the main ML function. This was due to the scope in which a symbol was
declared using externalFunctionSymbol. The attached example
call_c_test_13.tar.gz gives a simple example of the problem. The
external function symbol isn't being declared until run time so this
code is inadvertently depending on a feature of dynamic linking. I can
see that use of externalFunctionSymbol is inherently more restricted
that getSymbol: externalFunctionSymbol must be applied to a symbol name
at compile time but the symbol cannot be used until run time,
post-linking. Are there any sort of checks that could be done to warn
users if they get this wrong? I can see it's not straightforward
because run time is itself compile time for an exported function that is
subsequently linked. At the very least, could an exception be raised
rather than seg faulting if there is an attempt to use an unresolved
symbol?
I've been thinking about that. The symbol is created with a zero
address. The actually address is set by the linker. It now raises an
exception if it tries to use a symbol when the value is zero.
Finally, is there a reason you chose the name "externalFunctionSymbol"
rather than, say, "externalSymbol"? It seems to work fine for
non-functions too - see attached example call_c_test_14.tar.gz .
On the X86 and most platforms the same linker symbols are used for both
function code and data. There are a very few platforms that use
different relocations for these. See commit 76b36c9d. I've added
externalDataSymbol for data.
Regards,
David
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml