From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66433 invoked by alias); 17 Dec 2015 15:30:28 -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 66411 invoked by uid 89); 17 Dec 2015 15:30:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=cif, H*Ad:U*libffi-discuss X-HELO: e06smtp05.uk.ibm.com Received: from e06smtp05.uk.ibm.com (HELO e06smtp05.uk.ibm.com) (195.75.94.101) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Thu, 17 Dec 2015 15:30:26 +0000 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 17 Dec 2015 15:30:23 -0000 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 17 Dec 2015 15:30:20 -0000 X-IBM-Helo: d06dlp02.portsmouth.uk.ibm.com X-IBM-MailFrom: uweigand@de.ibm.com X-IBM-RcptTo: libffi-discuss@sourceware.org Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 3A724219005F for ; Thu, 17 Dec 2015 15:30:11 +0000 (GMT) Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id tBHFUJwj11207158 for ; Thu, 17 Dec 2015 15:30:19 GMT Received: from d06av10.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id tBHEUK10006133 for ; Thu, 17 Dec 2015 07:30:20 -0700 Received: from oc7340732750.ibm.com (dyn-9-152-213-193.boeblingen.de.ibm.com [9.152.213.193]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id tBHEUKZO006121; Thu, 17 Dec 2015 07:30:20 -0700 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id CDD291513; Thu, 17 Dec 2015 16:30:18 +0100 (CET) Subject: Re: s390x ffi_closure_helper_SYSV To: planrichi@gmail.com (Richard Plangger) Date: Thu, 17 Dec 2015 15:30:00 -0000 From: "Ulrich Weigand" Cc: libffi-discuss@sourceware.org In-Reply-To: <5672CF2D.2030401@gmail.com> from "Richard Plangger" at Dec 17, 2015 04:05:17 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20151217153018.CDD291513@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15121715-0021-0000-0000-00000534EAF8 X-SW-Source: 2015/txt/msg00102.txt.bz2 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 -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com