On 21/11/11 16:46, David Matthews wrote:
On 21/11/2011 14:19, Phil Clayton wrote:On 21/11/11 11:33, David Matthews wrote: This now works on Fedora 15 x86_64 without the symbolic links. I also tested Fedora 12 x86_64 with and without the libffi-devel package and both scenarios worked 'out of the box' i.e. no sym links required.I also ran tests on a Fedora 14 i386 machine. These were not to successful. Without libffi, build failed during 'make' - see attached file log-nolibffi-f14-i386.txt. With libffi, a callback caused a seg fault. I can supply an example but wondered if you were still tweaking the i386 stuff? One minor comment: for x86_64, the Foreign exn message for structs and doubles could, perhaps, usefully indicate libffi is required like it now does for callbacks. PhilI've fixed a problem with the non-libffi callback code so it now seems to compile without libffi. I don't understand the seg-fault with libffi and Fedora 14. Perhaps there's a problem with the version of the library in that version. I don't have any easy way of testing it myself so any debugging you can do would be helpful.
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.
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.)
Phil
eg1.tar.gz
Description: GNU Zip compressed data
_______________________________________________ polyml mailing list [email protected] http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
