Hi David,
Thanks for the explanation and updates. I have tested this, including
externalDataSymbol, and all appears to work on my Linux and Darwin systems.
Initially I found that I wasn't seeing the new Foreign exception for an
uninitalized external symbol, although there was no seg fault. It turns
out that was actually because the exception was occurring in a function
registered with PolyML.onEntry. It seems that PolyML.onEntry silently
suppresses any exceptions from the functions it runs. Is that intended?
I have been wondering if there is a way to have a local version of
external(Function|Data)Symbol that falls back on
getSymbol (loadExecutable ())
if the functions aren't available. Could this be achieved by using one
of two files depending on the value of PolyML.rtsVersion () ?
Thanks,
Phil
On 07/10/18 12:44, David Matthews wrote:
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
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
