This is the mail archive of the libffi-discuss@sourceware.org mailing list for the libffi project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libffi - the 10th Anniversary Release


Thomas Heller wrote:
Dalibor Topic schrieb:
Tom Tromey wrote:
Dalibor also pointed out this patch:

http://svn.python.org/view/ctypes/trunk/ctypes/win64.diff?rev=53398&view=auto

This adds Win64 support.

Tom
As ctypes is theller's code, and he seems to have a bunch of different libffi patches stuck away in branches,
I figured it's best to ping theller himself what to merge. I'd love to see the arm-wince stuff go in, but I have
nothing to test it myself.

Well, the libffi_msvc directory is a branch of the libffi sources, adapted so that they can be compiled with the MS compilers. Both for win32/x86 and win64/amd64. Both the cdecl and stdcall calling conventions are supported, also for closures. The ffi_call function has been changed to return an integer which informs about the stack pointer difference before and after the function call; this is to detect wrong calling convention or wrong number of parameters passed (in stdcall).

The libffi_asm_wince directory is for MS compilers and windows ce/arm, with
closure support.

Very cool. How hard would it be to adapt those for cegcc?
http://cegcc.sourceforge.net/ ... I guess the assembler syntax is quite different?



The changes to the libffi directory that I remember are these:


- New configure system (this was not written by me).  The goal was
  to have no GPL'd files in the Python svn repo.  Also the libffi sources
  are not compiled into a shared library, instead they are linked into
  the Python ctypes extension that uses it.

- We changed the libffi sources to use proper function prototypes
  since we have a zero-compiler-warning policy.  For example:

-extern void ffi_call_osf(void *, unsigned long, unsigned, void *, void (*)())
+extern void ffi_call_osf(void *, unsigned long, unsigned, void *, void (*)(void))


Sounds useful to me.


Is there a reason to keep these 'void (*)()' constructs?

I don't think so, Tom?


cheers,
dalibor topic


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]