Also: problem with return value in ffi_call on PPC64.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Also: problem with return value in ffi_call on PPC64.

Kaz Kylheku (libffi)
Hi all,

It turns out that return values from foreign calls are also not working
in the way I expect.

For instance, the int return value of dup comes out as zero if a file
descriptor is returned.
The -1 value emerges properly due to sign extension:

1> (with-dyn-lib nil (deffi dup-fd "dup" int (int)))
#:lib-0175
2> (dup-fd 0)
0
3> (dup-fd 4)
-1
4> (dup-fd 3)
0
5> (dup-fd 4)
0
6> (dup-fd 5)
0
7> (dup-fd 7)
-1
8> (dup-fd 7)
-1

Are users supposed to assume that the return value has been widened to a
register-wide (8 byte) value regardless of its declared FFI type?

Why doesn't that convention apply to the arguments, then? When dup is
being called above, the int value is being written at the bottom of the
argument buffer, not displaced by four bytes.

Reply | Threaded
Open this post in threaded view
|

Re: Also: problem with return value in ffi_call on PPC64.

Kaz Kylheku (libffi)
On 27.05.2017 18:36, Kaz Kylheku (libffi) wrote:
> Are users supposed to assume that the return value has been widened to
> a register-wide (8 byte) value regardless of its declared FFI type?

Indeed, it seems yes.

I now see in some documentation that "ffi_arg" C type must be used for
capturing return values.

I'm not a complete idiot; I was taken for a ride by the simple example
from some (perhaps outdated?) libffi texinfo documentation. This one:

      #include <stdio.h>
      #include <ffi.h>

      int main()
      {
        ffi_cif cif;
        ffi_type *args[1];
        void *values[1];
        char *s;
        int rc;

        /* Initialize the argument info vectors */
        args[0] = &ffi_type_pointer;
        values[0] = &s;

        /* Initialize the cif */
        if (ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 1,
                        &ffi_type_uint, args) == FFI_OK)
          {
            s = "Hello World!";
            ffi_call(&cif, puts, &rc, values);
            /* rc now holds the result of the call to puts */

            /* values holds a pointer to the function's arg, so to
               call puts() again all we need to do is change the
               value of s */
            s = "This is cool!";
            ffi_call(&cif, puts, &rc, values);
          }
        return 0;
      }

Here, the return buffer rc is just "int" and not "ffi_arg". So, this
isn't correct for PPC64. The rc variable isn't large enough to buffer
the return value, and will alias the wrong end of it.

Oops!

puts("This is .. not so cool!");

:)

Reply | Threaded
Open this post in threaded view
|

Re: Also: problem with return value in ffi_call on PPC64.

Sourceware - libffi-discuss mailing list
On Sat, 27 May 2017 19:15:35 -0700
"Kaz Kylheku (libffi)" <[hidden email]> wrote:

> > Are users supposed to assume that the return value has been widened to
> > a register-wide (8 byte) value regardless of its declared FFI type?  
>
> Indeed, it seems yes.

Confusingly yes. But only for integral types smaller that ffi_arg.

TL;DR:
   Instead of just reading out result as *(result_type*)r for any FFI
   type you need to use either *(ffi_arg*)r or *(result_type*)r depending
   on the type of the result.

A bit vague libffi thread:
    https://sourceware.org/ml/libffi-discuss/2010/msg00063.html

I discovered the same a few years ago debugging similar issue on GHC side
    https://ghc.haskell.org/trac/ghc/ticket/3516

The awkward fix on GHC side:
    https://git.haskell.org/ghc.git/commitdiff/3891512c4c770dadd0372ad84d2dec72b34652d2

Hope that helps.

--

  Sergei

attachment0 (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Also: problem with return value in ffi_call on PPC64.

Kaz Kylheku (libffi)
On 28.05.2017 11:22, Sergei Trofimovich wrote:
> On Sat, 27 May 2017 19:15:35 -0700
> "Kaz Kylheku (libffi)" <[hidden email]> wrote:
>
>> > Are users supposed to assume that the return value has been widened to
>> > a register-wide (8 byte) value regardless of its declared FFI type?
>>
>> Indeed, it seems yes.
>
> Confusingly yes. But only for integral types smaller that ffi_arg.

Thanks for your response and everyone else's.

I feverishly patched up all my code on Saturday night and got all my
test cases to pass on PPC64 with clean Valgrind, without regressing
on the little endian Intels.

My OOP-in-C framework that wraps around libffi basically absorbed this
change quite easily, with hardly much uglification. Just a proliferation
of boiler plate code.

(I never suspected it would be otherwise; but it was a question of
understanding the requirements first; having already acted hastily
on the somewhat wrong requirements already.)

Reply | Threaded
Open this post in threaded view
|

Re: Also: problem with return value in ffi_call on PPC64.

Andrew Haley
In reply to this post by Kaz Kylheku (libffi)
On 28/05/17 02:36, Kaz Kylheku (libffi) wrote:
> Are users supposed to assume that the return value has been widened to a
> register-wide (8 byte) value regardless of its declared FFI type?

Yes.

> Why doesn't that convention apply to the arguments, then? When dup is
> being called above, the int value is being written at the bottom of the
> argument buffer, not displaced by four bytes.

It's more of a historical accident than anything planned.  But it's not
important enough to break backwards compatibility.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671