From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128261 invoked by alias); 17 Dec 2015 19:32:08 -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 128250 invoked by uid 89); 17 Dec 2015 19:32:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=laptop, Bye, HTo:U*libffi-discuss X-HELO: mail-wm0-f46.google.com Received: from mail-wm0-f46.google.com (HELO mail-wm0-f46.google.com) (74.125.82.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 17 Dec 2015 19:32:06 +0000 Received: by mail-wm0-f46.google.com with SMTP id p187so35877233wmp.0 for ; Thu, 17 Dec 2015 11:32:05 -0800 (PST) X-Received: by 10.194.246.200 with SMTP id xy8mr29858832wjc.62.1450380722942; Thu, 17 Dec 2015 11:32:02 -0800 (PST) Received: from [192.168.0.102] (77.119.128.222.wireless.dyn.drei.com. [77.119.128.222]) by smtp.googlemail.com with ESMTPSA id b203sm3564060wmh.24.2015.12.17.11.32.01 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Dec 2015 11:32:01 -0800 (PST) Subject: Re: s390x ffi_closure_helper_SYSV To: libffi-discuss@sourceware.org References: <20151217153018.CDD291513@oc7340732750.ibm.com> From: Richard Plangger X-Enigmail-Draft-Status: N1110 Message-ID: <56730DB0.2080301@gmail.com> Date: Thu, 17 Dec 2015 19:32: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: <20151217153018.CDD291513@oc7340732750.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015/txt/msg00103.txt.bz2 Hi Ulrich, thx for your reply. I agree that it makes sense to return a full ffi_arg if the integral value is smaller than the machine register. However, I still think there is something not right with the s390 implementation. Please have a look at this program: https://gist.github.com/planrich/3fd72767812754d9104d The program pollutes a fairly large junk of memory below the frame pointer and then calls back to a python function (from c). Because the ret_buffer variable (in ffi_closure_helper_SYSV) is not initialized properly, the returned value is not the same on s390x as it is on e.g. x86. `make` on my laptop (x86) returns without asserting, but it does not on s390x. PPC was recently implemented on PyPy and there we did also not hit this issue. Cheers, Richard On 12/17/2015 04:30 PM, Ulrich Weigand wrote: > Richard Plangger wrote: > >> I hit an issue with libffi that was included in CPython 2.7.10. >> Here is the github issue: >> >> https://github.com/atgreen/libffi/pull/216 >> >> Let me know what you think. > > I think you're running into the special case with return values > that is described here in the libffi docs: > > In most situations, @samp{libffi} will handle promotion according to > the ABI. However, for historical reasons, there is a special case > with return values that must be handled by your code. In particular, > for integral (not @code{struct}) types that are narrower than the > system register size, the return value will be widened by > @samp{libffi}. @samp{libffi} provides a type, @code{ffi_arg}, that > can be used as the return type. For example, if the CIF was defined > with a return type of @code{char}, @samp{libffi} will try to store a > full @code{ffi_arg} into the return value. > > I.e. when a return value is described by any of the small integral > type codes, code is expected to actually return a full ffi_arg. > > While this is not explicitly mentioned in the closure docs, the > code makes the assumption that this is handled likewise for closure > return values. This is also explicitly checked for in the libffi > test suite, e.g. testsuite/libffi.call/cls_sshort.c > > While this is indeed somewhat surprising, I don't think we can > simply change the behavior at this point, as other existing > users may depend on current behavior. > > In any case, this is a cross-platform issue (though probably > exacerbated on big-endian platforms). > > Bye, > Ulrich >