[pypy-dev] s390x libffi issue

[Armin Rigo]

Hi Richard,

On Thu, Jan 14, 2016 at 6:32 PM, Richard Plangger <planrichi at gmail.com> wrote:
> <trace call> -- parameter (1213,1213) both 64-bit
>      <calls the python function that returns 1213+1213 = 2426
>       as 64bit integer> (2)

Do you mean in both cases 16-bit integer instead of 64-bit integer?

> returns every frame back to <trace call> and saves 0xdeadbeefdead097a

> My understanding is that: libffi expects that <trace call> should, just
> after returning the 64 bit value, cast the result to a 16 bit value.
> We cannot do that!

If I understand correctly, you can do exactly that.  After a call
instruction to a function that returns a 16 bits result, simply add
another instruction to sign- or zero-extend the result to a full
64-bit value.  Surely it is not a performance problem to add a
single simple instruction after some rare calls?

In more details: my point of view is that libffi is *documented* to
return the value
0x000000000000097a, but instead it returns 0xdeadbeefdead097a.  It's a
bug in libffi, but maybe one that is not going to be fixed promptly.
In that case, you can simply work around it.  Specifically,
after a "call_i" instruction that should return a 16-bit number: the
official ABI says it should return 0x000000000000097a; when called via
ctypes it returns 0xdeadbeefdead097a instead; so go for the careful
solution and only assume that the last 16 bits are valid, and emit an
instruction just after the call to sign- or zero-extend the result
from 16 bits to 64 bits.  Then you can leave the issue in the hands of
libffi for s390x and not be annoyed if it doesn't get fixed.


A bientôt,

Armin.