Also: problem with return value in ffi_call on PPC64.

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.

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

[Andrew Haley]

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

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!");

:)

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

[Sergei Trofimovich via libffi-discuss]

[-- Attachment #1: Type: text/plain, Size: 916 bytes --]

On Sat, 27 May 2017 19:15:35 -0700
"Kaz Kylheku (libffi)" <382-725-6798@kylheku.com> 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

[-- Attachment #2: Цифровая подпись OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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)" <382-725-6798@kylheku.com> 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.)