[pypy-dev] s390x libffi issue

[Richard Plangger]

Hi,

so far this issue is not resolved. Sadly the argument is that I/we
probably do not handle the return type of libffi correctly.

Let me explain the problem (again). For instance in the test [1]
the case lltype.FuncType([rffi.Short, rffi.Short], rffi.Short).

Here is what happens step by step (if not readable in the mail see [3]):

jit compiles trace:
<trace call> -- parameter (1213,1213) both 64-bit
     |
     v
ffi_closure_SYSV
     |
     v
ffi_closure_helper_SYSV (1)
     |
     v
< enters ctypes>
closure_fcn <callback.c>
     |
     v
_CallPythonObject <callback.c>
     |
     v
     <calls the python function that returns 1213+1213 = 2426
      as 64bit integer> (2)
     |
     v
     <calls h_set [2]. good, because we instructed it to do this> (3)
     contents of the buffer of (1) before the call: 0xdeadbeefdeadbeef
     contents of the buffer of (1) after  the call: 0xdeadbeefdead097a
     ||
     vv
returns every frame back to <trace call> and saves 0xdeadbeefdead097a
in the variable e.g. i42 = call_i(..., 1213, 1213)

(1) provides the stack location (3) writes the result to
(2) leads into ll2types.py internal_callback and returns 2426L

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! AFAIK the jit has no notion of a narrower integer
type than the machine register. The only exception is loading and
storing from/to memory that are later sign extended.

Any suggestions?

Cheers,
Richard

[1] rpython/jit/backend/test/runner_test.py:test_call
[2]
https://github.com/python/cpython/blob/1fe0fd9feb6a4472a9a1b186502eb9c0b2366326/Modules/_ctypes/cfield.c#L551
[3] http://paste.pound-python.org/show/hvcqL68eqUApEH0PhnuG/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160114/b1cf75e3/attachment.sig>