Re: RFC: variadic closures in x86/x86_64

[Philip Ashmore <contact@philipashmore.com>]

On 04/12/13 08:02, Hogan, D. (GE Power & Water) wrote:
> On Wed, Nov 27, 2013 at 00:57:23PM +1030, Alan Modra wrote:
>> The claim to fame looks to be the ability to call variadic functions
>> without describing the arguments via ffi_prep_cif_var at the point of
>> call.  Instead you do so in the function consuming the args.  I'm not
>> sure what that gains you..
> 
> This is specifically for variadic callbacks.  If it wasn't a callback,
> I could use ffi_prep_cif_var.
> 
> To give a little background, FMI is a standard for (among other things)
> model exchange so you can use a dynamic system model in various
> modeling or simulation environments.  The model is exposed as a C shared
> library.  The shared library executes callbacks (some variadic) provided
> by a FMU driver.
> 
> JFMI allows you to drive a FMU from Java.  The Java FMU driver provides
> a Java implementation for the C callbacks.  The nonvariadic callbacks
> were already supported by JFMI through libffi and JNA.  In order to
> handle variadic callbacks, libffi and JNA need to be modified so you
> can access the variadic arguments inside of a callback.  This patch
> adds the libffi support.
> 
> I cannot construct a ffi_prep_cif_var because the model's C shared
> library is the one running a variadic callback in the driver.  I don't
> know how many arguments or what types it will provide in the calls.  I
> have to rely on printf style formatting flags in order to know what to
> access from inside of the callback.
> 
>> The patch suffers from the same flaw as my first attempt at adding
>> variadic argument support for PowerPC64 ELFv2, namely that you cannot
>> add fields to ffi_cif without breaking ABI compatibility.
>> Applications linked against an older version of libffi.so will supply
>> the old ffi_cif to a new shared library..
> 
> That's a good point.  This should be changed to avoid breaking the ABI.
> 
I may be talking through my hat but if there's a format argument then
couldn't you provide a function to parse it and then prepare other cifs
on an as-needed basis? The key would be the concatenation of all the
types in the format argument.

That way you wouldn't need to modify libffi.

Regards,
Philip Ashmore