libffi - the 10th Anniversary Release

Dalibor Topic robilad@kaffe.org
Tue Jan 29 19:33:00 GMT 2008


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



More information about the Libffi-discuss mailing list