Re: [PATCH] win64 support for libffi (2/2)

[Timothy Wall <twalljava at dev dot java dot net>]

On May 18, 2009, at 10:37 AM, Andrew Haley wrote:

> Timothy Wall wrote:
> > On May 18, 2009, at 6:11 AM, Andrew Haley wrote:
> >
> > > Some of your patch seems odd to me, and perhaps changes are needed.
> > >
> > > For example, why this change?
> > >
> > > @@ -62,41 +71,59 @@
> > >      size_t z;
> > >
> > >      /* Align if necessary */
> > > -      if ((sizeof(int) - 1) & (unsigned) argp)
> > > -       argp = (char *) ALIGN(argp, sizeof(int));
> > > +      if ((sizeof(void*) - 1) & (size_t) argp)
> > > +        argp = (char *) ALIGN(argp, sizeof(void*));
> >
> > sizeof(void*) would probably be more accurately represented by
> > sizeof(ffi_arg), although the effect is the same.  win64 is looking  
> > for
> > a 64-bit alignment, versus the original 32-bit alignment.
>
> But this is in 32-bit generic code.  I take it that the file ffi.c,  
> which
> is used for 32-bit code on Linux, is also to be used for 64-bit code  
> on
> Windows, which is still using the old calling convention of passing  
> args
> via memory rather than registers.
>
> OK, I think I get it now.
>
> A warning to that effect for Linux maintainers might be a good idea.

The implementation isn't terribly optimized; I started from Thomas  
Heller's python ctypes implementation, which re-used the 32-bit ffi.c  
code.  I suppose ideally you'd have a separate source file for the  
win64 stuff (ala darwin64/unix64/etc) but the calling conventions  
originally looked similar enough that splitting it out didn't seem  
like it was worth the effort.

I'll re-do diffs against gcc libffi.