public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
* Cosure return value issue on Linux PPC64
@ 2017-05-27 16:59 Kaz Kylheku (libffi)
  2017-05-29  7:44 ` Andrew Haley
  2017-05-29 12:31 ` Tom Tromey
  0 siblings, 2 replies; 4+ messages in thread
From: Kaz Kylheku (libffi) @ 2017-05-27 16:59 UTC (permalink / raw)
  To: libffi-discuss

Hi all,

My interpreted language's test suite failed on a PPC64 Linux box 
(gcc110.fsffrance.org).

The test in question uses the qsort C library function to sort a Lisp 
vector, using a Lisp callback.

Unfortunately, the int return value from the callback turns to garbage.  
The problem reproduces with current libffi from git.

The following test patch makes the problem go away and all tests pass:


diff --git a/src/powerpc/linux64_closure.S 
b/src/powerpc/linux64_closure.S
index 6487d2a..28a191a 100644
--- a/src/powerpc/linux64_closure.S
+++ b/src/powerpc/linux64_closure.S
@@ -27,7 +27,8 @@
  #define LIBFFI_ASM
  #include <fficonfig.h>
  #include <ffi.h>
-
+#undef __LITTLE_ENDIAN__
+#define __LITTLE_ENDIAN__ 1
         .file   "linux64_closure.S"

  #ifdef POWERPC64


The problem is that all the big endian cases are expecting the caller to 
place the return value at a displaced address.  If the type is int, for 
instance, the expectation is that the return value is to be stored at 
*(int *)(retval + 4).  If it is short, then at *(short *)(retval + 6) 
and so on.

Is this documented somewhere?

My code is storing everything at just the retval base address, 
regardless of size.

Cheers ...

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Cosure return value issue on Linux PPC64
  2017-05-27 16:59 Cosure return value issue on Linux PPC64 Kaz Kylheku (libffi)
@ 2017-05-29  7:44 ` Andrew Haley
  2017-05-29 12:31 ` Tom Tromey
  1 sibling, 0 replies; 4+ messages in thread
From: Andrew Haley @ 2017-05-29  7:44 UTC (permalink / raw)
  To: libffi-discuss

On 27/05/17 17:59, Kaz Kylheku (libffi) wrote:
> 
> The problem is that all the big endian cases are expecting the caller to 
> place the return value at a displaced address.  If the type is int, for 
> instance, the expectation is that the return value is to be stored at 
> *(int *)(retval + 4).  If it is short, then at *(short *)(retval + 6) 
> and so on.
> 
> Is this documented somewhere?
> 
> My code is storing everything at just the retval base address, 
> regardless of size.

On a 64-bit target, use word loads for your return values and cast them
accordingly.  So, don't use

  *(int *)(retval + 4)

use

  (int)*retval

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Cosure return value issue on Linux PPC64
  2017-05-27 16:59 Cosure return value issue on Linux PPC64 Kaz Kylheku (libffi)
  2017-05-29  7:44 ` Andrew Haley
@ 2017-05-29 12:31 ` Tom Tromey
  2017-05-29 15:30   ` Andrew Haley
  1 sibling, 1 reply; 4+ messages in thread
From: Tom Tromey @ 2017-05-29 12:31 UTC (permalink / raw)
  To: Kaz Kylheku (libffi); +Cc: libffi-discuss

Kaz> Is this documented somewhere?

A while back I tried to document all these little oddities in the
manual.  It's difficult and ABI-breaking to fix libffi to be more in
line with user expectation, but at least in the meantime the docs can be
correct...

The closure docs say:

    @item ret
    [...]
    Otherwise, @var{fun} must fill the object to which this points,
    following the same special promotion behavior as @code{ffi_call}.
    That is, in most cases, @var{ret} points to an object of exactly the
    size of the type specified when @var{cif} was constructed.  However,
    integral types narrower than the system register size are widened.  In
    these cases your program may assume that @var{ret} points to an
    @code{ffi_arg} object.

I hope this helps, but if it's still insufficiently clear, I'd
appreciate suggestions for how to improve it.

From your other note:

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

You're definitely not an idiot, this has bitten many people, has been
asked on StackOverflow, has been filed as a bug in github a few times,
etc.

Alan Modra fixed up this documentation example back in 2013, according
to git blame.  Seems like libffi is overdue for a release :-)

Anyway, I think the in-tree docs should be a bit clearer here.  For
example they mention the promotion behavior now.

Tom

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Cosure return value issue on Linux PPC64
  2017-05-29 12:31 ` Tom Tromey
@ 2017-05-29 15:30   ` Andrew Haley
  0 siblings, 0 replies; 4+ messages in thread
From: Andrew Haley @ 2017-05-29 15:30 UTC (permalink / raw)
  To: Tom Tromey, Kaz Kylheku (libffi); +Cc: libffi-discuss

On 29/05/17 13:31, Tom Tromey wrote:
> I hope this helps, but if it's still insufficiently clear, I'd
> appreciate suggestions for how to improve it.

A couple of examples would help.  I find that wordage confusing.

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-05-29 15:30 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-27 16:59 Cosure return value issue on Linux PPC64 Kaz Kylheku (libffi)
2017-05-29  7:44 ` Andrew Haley
2017-05-29 12:31 ` Tom Tromey
2017-05-29 15:30   ` Andrew Haley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).