On 22/11/2011 16:35, Phil Clayton wrote:
On 21/11/11 16:46, David Matthews wrote:
I have tried libffi 3.10.0 and the latest 3.11.0-rc2 and the seg fault
still occurs. I've attached a simple example but it's nothing special.
I can explain what is happening, but not ultimately why.
The seg fault occurs when attempting to call a function pointer passed
to a C foreign function. It is hard to say whether the pointer is duff.
The pointer value was created by the call to ffi_closure_alloc in
foreign.cpp, line 1841 and returned in resultFunction. For the attached
example, the function pointer, written to resultFunction, is 0x115008
and closure, the return value of ffi_closure_alloc, is 0x116008. (On my
x86_64 machine, resultFunction is 4K higher, not lower.)
When debugging, if I set cb1 to 0x116008 instead, it all works - no seg
fault. I don't understand why calling 0x116008 (closure) works and
0x115008 (resultFunction) doesn't: the comments in ffi_closure_alloc
suggest that resultFunction is "the executable corresponding virtual
address" of closure.
Thanks for testing the patch we discussed off-line. I've now committed
it so it looks like this is fixed.
Now I've managed to get libffi working in mingw/msys I'm rather inclined
to remove the non-libffi code completely. The build process for Poly/ML
would then not include the CInterface structure at all if libffi were
not installed, much like X-windows.
Given the extensive list of platforms supported by libffi, that seems
reasonable. Is it just me who has this issue with i386/Linux then?
(Personally, I only need x86_64.)
libffi runs on all the platforms I've tried but there are issues with
packages which makes it difficult to rely on using an external package
to build Poly/ML. As well as mingw/mys there is a problem with Cygwin.
Although libffi is available as a binary library there is no
development package with the headers and link library so building on
Cygwin is going to require the libffi sources. Cygwin is an important
platform for Isabelle so Poly/ML needs to be able to build fairly easily
on it.
David
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
