From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123601 invoked by alias); 4 Jan 2016 16:54:32 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 123571 invoked by uid 89); 4 Jan 2016 16:54:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=closure, H*r:sk:libffi-, Modules, behaves X-HELO: mail-wm0-f66.google.com Received: from mail-wm0-f66.google.com (HELO mail-wm0-f66.google.com) (74.125.82.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 04 Jan 2016 16:54:30 +0000 Received: by mail-wm0-f66.google.com with SMTP id f206so29400527wmf.2 for ; Mon, 04 Jan 2016 08:54:29 -0800 (PST) X-Received: by 10.194.249.69 with SMTP id ys5mr92512942wjc.97.1451926467215; Mon, 04 Jan 2016 08:54:27 -0800 (PST) Received: from [192.168.0.102] (77.119.129.222.wireless.dyn.drei.com. [77.119.129.222]) by smtp.googlemail.com with ESMTPSA id jm4sm86724806wjb.7.2016.01.04.08.54.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jan 2016 08:54:25 -0800 (PST) Subject: Re: s390x ffi_closure_helper_SYSV References: <20151221183930.372366414@oc7340732750.ibm.com> From: Richard Plangger X-Enigmail-Draft-Status: N1110 To: uweigand@de.ibm.com Cc: libffi-discuss@sourceware.org Message-ID: <568AA3AD.9000709@gmail.com> Date: Mon, 04 Jan 2016 16:54:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151221183930.372366414@oc7340732750.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LLtFNHUGVGhWgifUBwdfGBCvECjW5BsV0" X-IsSubscribed: yes X-SW-Source: 2016/txt/msg00000.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LLtFNHUGVGhWgifUBwdfGBCvECjW5BsV0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-length: 1809 Hi and happy new year, I have further investigated this issue. Sorry to be so persistent, but I still think something is not quite right here. To show my point: here is a comparison between x86_64 (I assume this is most tested platform for libffi) and s390x. In short: on x86_64 the closure helper behaves differently processing the return value. Here are some gdb steps in the x86_64 linux implementation: https://gist.github.com/planrich/fd25c31213ba565116a9 In a nutshell: I broke at the assembly position at https://github.com/python/cpython/blob/master/Modules/_ctypes/libffi/src/x8= 6/unix64.S#L269 of my small ctypes sample program. (https://gist.github.com/planrich/3fd72767812754d9104d) As far as I can tell (on x86_64) ffi_closure_unix64_inner is the equivalent to ffi_closure_helper_SYSV on s390x. If the above is correct then: movzx eax,WORD PTR [rsp-0x18] zero extends the 16 bit value to a full 64bit value. That is what my initial patch is all about, s390x does not do this zero/sign extension just after invoking the user closure. > The point is that if the user-callback were to fill in a full ffi_arg, > then ret_buffer would be completely filled. If ret_buffer isn't fully > written, then that's a bug in the callback PyPy provides to libffi. The closure return value (which is written on the stack location of ret_buffer on s390x) is filled in ctypes here: https://github.com/python/cpython/blob/master/Modules/_ctypes/cfield.c#L551 This would mean that ctypes only writes 16 bits into ret_buffer? I have also debugged it, and it does only store 16 bits. If I'm wrong, could someone please point out the issue with my sample program? Cheers, Richard P.S. I have looked at the PPC asm implementation as well, there it is also zero/sign extended to the machine register size. --LLtFNHUGVGhWgifUBwdfGBCvECjW5BsV0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWiqPAAAoJENA/KjVJQp8L6PsQAJkD9sE7CNLfTFvX5P7WYAxq ab7l5tJuzl8AkrNFbvzSToNtfVLVYkLCoowSZus1rrgtB56YNkzgjaFb1Um13XZA Rl7XTK8rUepSqa5O7ZxuBj3chRuTh9ApuphaTwO3VP9D3wPfA/Z/AqofAZ1aQd0p /HwvYkSSDbklEHbdwDDGsxcfx3qjd20AFlxafx2Tt7SWfaX5CyY0v7TW5cD7K/KU X1iXdyFJ4L7a9uxGNgazvEuvm+KR8JjHbX6ZXQyk7ww6pFhDXuzscPL8eAtXWmmw 0p1DqOKZ4/KaKBFDOJqgp+hrHBIPVDOboQGsUbYHlQ92UmHoYsK5vW/aFDoJN2jd QKunBjltoPLRETONZnKoapRhiHW336rFgvJ/iMZLSCxd/q1XUtZfMFOtLUbxjfMR M7C7wKPeRG7GnMkz8tDPD43zFTE0Wc76T77+3y9ahszSGD3IB4FM4TndZnte2b/1 OLL6/O2B8BMdta7jqXhVFwbejVKUU8h8MmqOG5bbSm2mJ+0Bl4c1PRsQP7jQy/fQ xWMuUrVUTo+BT1HtupAL2hlI9gz1ULFlHgOle/lHSM/6Wx4u1G2kZo+4v77kmxkQ p2obyWCCe7qEGNfOFMkjAxc6KNTBJXhjSrkOrUfd9RG0a4PDqK4j3ZGl0ReX5V1j ZJC/l4cC2aBLZqjLinri =4Vm+ -----END PGP SIGNATURE----- --LLtFNHUGVGhWgifUBwdfGBCvECjW5BsV0--