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: Variadic functions and libffi


On 01/05/2011 05:47 PM, David Gilbert wrote:

>    As part of the linaro toolchain effort for ARM, I've been asked to
> look at Variadic function calls in libffi,
> specifically for the ARM 'hard float' (aka PCS_VFP or FFI_VFP, armhf)
> variant and wanted to see what
> people thought before I dived in to it.
>
>    The ARM hard float variant is a variant of the ABI in which floating
> point values are passed in floating point
> registers (as opposed to the standard ABI where FP values are still
> passed in integer registers).  What makes
> this ABI a little unusual is that for variadic functions it just falls
> back to the standard all-integer-register ABI, and
> thus, as an example, in the function:
>
>     double foo(double bar, char *str, ...)
>
> the return value and the 'bar' would be passed in integer registers
> even though they aren't actually variadic
> parameters.

Oh dear.  I was hoping that this was never going to happen: we just use a
common ABI, and we've basically ignored the issue.

> It doesn't seem like there is any way out of this except for an API
> change to libffi to state that a variadic function is being
> called - so as I see it the questions then are:
>
>     1) Does libffi really support variadic functions and/or is there a
> desire to?  There are big warnings in various places saying
>   it doesn't - but then the testcases call variadic functions, and at
> least Python and SWIG both show examples of using it (with FP values).

Right, and often targets use the same ABI for both n-adic and
variadic functions, so it doesn't matter.

> I've had some discussion with Marcus Shawcroft (cc'd) and it looks
> like the right solution is to declare a
>
> 'ffi_prep_cif_variadic'

I guess this is basically OK, as it can default to ffi_prep_cif on all
the targets where there is no difference.  It might open a real can of
worms, though.

Let this be a lesson to all ABI designers...

Andrew.


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