[pypy-dev] s390x libffi issue

[David Edelsohn]

On Fri, Jan 15, 2016 at 3:33 AM, Armin Rigo <arigo at tunes.org> wrote:
> 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.

libffi is *documented* to return the non sign-extended value.

- David