This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: closure api return value types problem
- From: Andrew Haley <aph at redhat dot com>
- To: Sergei Trofimovich <slyich at gmail dot com>
- Cc: Sergei Trofimovich <slyfox at inbox dot ru>, libffi-discuss at sourceware dot org, Jakub Jelinek <jakub at redhat dot com>, Anthony Green <green at moxielogic dot com>
- Date: Fri, 02 Apr 2010 09:40:31 +0100
- Subject: Re: closure api return value types problem
- References: <20100320102718.7029c1a0@mosly> <20100320142429.435b6ff9@mosly>
On 20/03/10 12:24, Sergei Trofimovich wrote:
>> Some time ago ghc project[1] switched to libffi to handle
>> foreign calls from/to external world. When I tried ghc on
>> powerpc64 I got some problems which I believe are result
>> of that switch.
>>
>> In one of FFI call types ghc uses C code generation and produces
>> following code:
>>
>> void haskell_closure_called_from_c(
>> void *cif __UNUSED__,
>> void* resp,
>> void** args,
>> void* haskell_runtime)
>> {
>> HaskellObj ret;
>> HsInt32 cret;
>>
>> ret = RT_CALL(haskell_runtime(args));
>>
>> cret=rts_getInt32(ret);
>> *(HsInt32*)resp = cret; /* <- is that corrct code? */
>> }
>
> Just looked at cls_ushort.c(and other integrals) test:
> *(ffi_arg*)resp = *(unsigned short *)args[0];
> and cls_float.c
> *(float *)resp = *(float *)args[0];
>
> Integrals seem to strangely be casted to 'ffi_arg *'(long *) while FPU ones
> are casted to their real type. It's normal (but undocumented) or it's a
> horrible inconsistency bug?
If you came up with a small self-contained test case it'd help a lot.
Andrew.