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

[Iavor Diatchki]

Hello,

just as another data point: I'd also find this functionality useful.  I've
run into the problem when trying to bind to C libraries that have functions
with struct parameters being passed by value, or returned (the idea being
that under the hood these structs often end up split up across registers).
  In the library I was working with, colors were implemented as RGBA
structs which were passed and returned by value all over the place.

-Iavor




On Sat, Jun 14, 2014 at 8:57 AM, Yuras Shumovich <shumovichy at gmail.com>
wrote:

> Hello,
>
> I implemented support for returning C structures by value in cmm for
> x86_64 (most likely it works only on linux). You can find it here:
> https://github.com/Yuras/ghc/commits/cmm-cstruct
>
> It supports I8, I16, I32, I64, F_, D_ cmm types, and  requires special
> annotation. For example:
>
> #include "Cmm.h"
>
> #define MyStruct struct(CInt, I8, struct(I8, CInt))
>
> cmm_test(W_ i)
> {
>   CInt i1;
>   I8 i2, i3;
>   float32 i4;
>   (i1, i2, i3, i4) = ccall c_test(W_TO_INT(i)) MyStruct;
>   return (TO_W_(i1), TO_W_(i2), TO_W_(i3), i4);
> }
>
> (See "test" directory for full examples.)
>
>
> Do you think it is right approach?
> Could anyone review the code please?
>
> And the last thing, I need mentor for this project. Is anyone interested?
>
> Thanks,
> Yuras
>
> On Tue, 2014-03-18 at 21:30 +0000, Simon Marlow wrote:
> > 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
> > >>
> > >
> > >
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140614/0f46954c/attachment.html>