From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7969 invoked by alias); 22 Oct 2017 18:28:21 -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 7215 invoked by uid 89); 22 Oct 2017 18:28:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FROM_STARTS_WITH_NUMS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=promotes, flaw, HX-PHP-Originating-Script:501 X-HELO: smtp-out-so.shaw.ca Received: from smtp-out-so.shaw.ca (HELO smtp-out-so.shaw.ca) (64.59.136.139) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 22 Oct 2017 18:28:18 +0000 Received: from kylheku.com ([70.79.163.252]) by shaw.ca with SMTP id 6KyseFECX8LPZ6KytezdKS; Sun, 22 Oct 2017 12:28:17 -0600 X-Authority-Analysis: v=2.2 cv=e552ceh/ c=1 sm=1 tr=0 a=95A0EdhkF1LMGt25d7h1IQ==:117 a=95A0EdhkF1LMGt25d7h1IQ==:17 a=IkcTkHD0fZMA:10 a=SMorJkV_YP8A:10 a=02M-m0pO-4AA:10 a=2KUf1mbJAAAA:8 a=_cYwNTAOEEgfrHJAjewA:9 a=KRnLf6-Fm4C04vCA:21 a=PezExFCwqOT5wQ3v:21 a=QEXdDO2ut3YA:10 a=LME9DoRMzU6P72L8X6EC:22 Received: from www-data by kylheku.com with local (Exim 4.72) (envelope-from <382-725-6798@kylheku.com>) id 1e6Kys-0000cz-AZ; Sun, 22 Oct 2017 11:28:14 -0700 To: Bruno Haible Subject: Re: test results on many platforms X-PHP-Originating-Script: 501:rcmail.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Oct 2017 18:28:00 -0000 From: "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com> Cc: libffi-discuss@sourceware.org In-Reply-To: <2437301.0N14NqkuRT@omega> References: <2437301.0N14NqkuRT@omega> Message-ID: X-Sender: 382-725-6798@kylheku.com User-Agent: Roundcube Webmail/0.9.2 X-CMAE-Envelope: MS4wfP5sPuZ9G96RQzeOjvBAstNPhlTM+yk0ShfUTBhagFBge+dBG7PU2OruVKyvn57MgKo5XAr/14IaMtR5GxLATmpJ6yr1vbx2kcV1aUoBmIBLs7QLlFfU jHXE1sCeK5Ou6AhHwzHpafutF9++4cnArlYMBbvh4I0Wx7Ev83OzMDwN1Oa55oDMmmU/1TysHyKp8UT5gxzCTo7xzahd1l8uIZQ= X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00024.txt.bz2 Hi Bruno, I suspect that some of your ffi_call bug reports on 64 bits may be=20 invalid. The return value on 64 bits, of small types, requires special treatment due to known quirk/design flaw in the API. It was originally not=20 documented, and then it was just documented as is. The way your code is doing it is how it *should* be, but isn't. Firstly, you must allocate a full "ffi_arg" word for the return value. You can't just use a &int_variable pointer for the return value of type int. The "ffi_arg" is in fact a 64 bit word. Secondly, the return value comes out aligned funny inside this word on big endian platforms. It is not at the base address as it would be on little endian, but rather the value of the wider ffi_arg word is the return value: in other words, the "int" is in the high order bytes which are four bytes above the base address. This situation bears some resemblance to promotion in the C language! Or, rather, not the type promotion from char/short to int as much as the widening in old-style calls: how char and short arguments are=20 actually int arguments: int old_style(arg) char arg; { /*...*/ } the argument is really of type int. When we call old_style((char) 42), promotion dove-tails with this: the char expression promotes to int, and so the correct call is generated, nonexistence of prototype notwithstanding. In libffi return value passage, every integer type smaller than ffi_arg is "promoted" to ffi_arg. Naively written code will appear to work fine on little endian 64 bit, such as x86_64, and then flop on, say, PPC64. I ran into this in the TXR Lisp FFI, resulting in this commit: http://www.kylheku.com/cgit/txr/commit/ffi.c?id=3D10507446389cff9b072c25aa8= 6ba35834a786fe5 My FFI type systems's virtual functions for doing "put" and "get" memory operations had to be split into "put", "rput", "get" and "rget" with the "r" variants doing the right thing for return values. The pad_retval macro calculates a padded size for any given type if it is used as a return value. Many thanks to the helpful hints from this mailing list.