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

[Edward Kmett]

I spent some time hacking around on this from a library perspective when I
had to interoperate with a bunch of Objective C on a 64-bit mac as many of
the core library functions you need to FFI out to pass around pairs of Int32s
as a struct small enough by the x64 ABI to get shoehorned into one
register, and as I was programmatically cloning Objective C APIs via
template haskell I couldn't use the usual clunky C shims.

What I was doing was just using libffi with a lot of work to cache the
results of ffi_prep_cif for each signature.

It worked reasonably well for my purposes, but my need for it vanished and
I abandoned the code in the middle of refactoring it for grander things.

So if nothing else, you can at least take this as a vote of confidence that
your idea isn't crazy. =)

I'd also be happy to answer questions if you get stuck or need help.

-Edward


On Fri, Mar 14, 2014 at 7:50 AM, Yuras Shumovich <shumovichy at gmail.com>wrote:

>
> Hi,
>
> Right now ghc's FFI doesn't support c/c++ structures.
>
> Whenever we have foreign function that accepts or returns struct by
> value, we have to create wrapper that accepts or returns pointer to
> struct. It is inconvenient, but actually not a big deal.
>
> But there is no easy workaround when you want to export haskell function
> to use it with c/c++ API that requires structures to be passed by value
> (Usually it is a callback in c/c++ API. You can't change it's signature,
> and if it doesn't provide some kind of "void* userdata", then you are
> stuck.)
>
> I'm interested in fixing that. I'm going to start with 'foreign import
> "wrapper" ...' stuff.
>
> Calling conventions for passing c/c++ structures by value are pretty
> tricky and platform/compiler specific. So initially I'll use libffi for
> that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see
> rts/Adjustor.c). It will allow me to explore design space without
> bothering about low level implementation details. Later it could be
> implemented for native (non-libffi) adjustors.
>
> Is anybody interested it that? I appreciate any comments/ideas.
>
> Right now I don't have clear design. It would be nice to support plain
> haskell data types that are 1) not recursive, 2) has one constructor and
> 3) contains only c/c++ types. But it doesn't work with c/c++ unions. Any
> ideas are welcome.
>
> An example how to use libffi with structures:
> http://www.atmark-techno.com/~yashi/libffi.html#Structures
>
> Thanks,
> Yuras
>
>
> _______________________________________________
> 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/20140314/ae3924aa/attachment.html>