FFI: c/c++ struct on stack as an argument or return value

[Simon Marlow]

So the hard parts are:

  - the native code generators
  - native adjustor support (rts/Adjustor.c)

Everything else is relatively striaghtforward: we use libffi for 
adjustors on some platforms and for GHCi, and the LLVM backend should be 
quite easy too.

I would at least take a look at the hard bits and see whether you think 
it's going to be possible to extend these to handle struct args/returns. 
  Because if not, then the idea is a dead end.  Or maybe we will need to 
limit the scope to make things easier (e.g. only integer and pointer 
fields).

Cheers,
Simon

On 18/03/2014 17:31, Yuras Shumovich wrote:
> Hi,
>
> I thought I have lost the battle :)
> Thank you for the support, Simon!
>
> I'm interested in full featured solution: arguments, return value,
> foreign import, foreign export, etc. But it is too much for me to do it
> all at once. So I started with dynamic wrapper.
>
> The plan is to support structs as arguments and return value for dynamic
> wrapper using libffi;
> then implement native adjustors at least for x86_64 linux;
> then make final design decision (tuple or data? language pragma? union
> support? etc);
> and only then start working on foreign import.
>
> But I'm open for suggestions. Just let me know if you think it is better
> to start with return value support for foreign import.
>
> Thanks,
> Yuras
>
> On Tue, 2014-03-18 at 12:19 +0000, Simon Marlow wrote:
>> I'm really keen to have support for returning structs in particular.
>> Passing structs less so, because working around the lack of struct
>> passing isn't nearly as onerous as working around the lack of struct
>> returns.  Returning multiple values from a C function is a real pain
>> without struct returns: you have to either allocate some memory in
>> Haskell or in C, and both methods are needlessly complex and slow.
>> (though allocating in Haskell is usually better.) C++ code does this all
>> the time, so if you're wrapping C++ code for calling from Haskell, the
>> lack of multiple returns bites a lot.
>>
>> In fact implementing this is on my todo list, I'm really glad to see
>> someone else is planning to do it :-)
>>
>> The vague plan I had in my head was to allow the return value of a
>> foreign import to be a tuple containing marshallable types, which would
>> map to the appropriate return convention for a struct on the current
>> platform.  Perhaps allowing it to be an arbitrary single-constructor
>> type is better, because it allows us to use a type that has a Storable
>> instance.
>>
>> Cheers,
>> Simon
>>
>
>