From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23513 invoked by alias); 6 Jan 2015 10:21:30 -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 23501 invoked by uid 89); 6 Jan 2015 10:21:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: swip.net Received: from mailfe07.swip.net (HELO swip.net) (212.247.154.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Jan 2015 10:21:26 +0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received: from [77.247.181.165] (account cxu-bx4-3f4@tele2.se HELO mail) by mailfe07.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPSA id 561674558 for libffi-discuss@sourceware.org; Tue, 06 Jan 2015 11:21:20 +0100 Received-SPF: none receiver=mailfe07.swip.net; client-ip=77.247.181.165; envelope-from=u-xsnf@aetey.se Received: (qmail 29018 invoked from network); 6 Jan 2015 10:19:36 -0000 Received: from unknown (HELO aetey.se) (eh1ba719@127.0.0.1) by mail with ESMTPA; 6 Jan 2015 10:19:36 -0000 Date: Tue, 06 Jan 2015 10:21:00 -0000 From: u-xsnf@aetey.se To: Richard Henderson Cc: libffi-discuss@sourceware.org Subject: Re: showstopper bug on x86 (Re: libffi does not follow proper ABI on ia32) Message-ID: <20150106102102.GF14316@example.net> References: <20141222193538.GW14316@example.net> <20141224135825.GF14316@example.net> <549AEA51.2000500@redhat.com> <54A4207F.9090904@redhat.com> <20150102185653.GO14316@example.net> <54A719A6.9050008@redhat.com> <20150103101457.GP14316@example.net> <54AB036B.4030104@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54AB036B.4030104@redhat.com> X-IsSubscribed: yes X-SW-Source: 2015/txt/msg00005.txt.bz2 Hello Richard, On Mon, Jan 05, 2015 at 01:34:35PM -0800, Richard Henderson wrote: > On 01/03/2015 02:14 AM, u-xsnf@aetey.se wrote: > > Is it hard to make libffi implementation compatible with cdecl? > > The calling conventions is exactly what the library is competent about. > > I guess it wasn't that hard. > > See https://github.com/atgreen/libffi/pull/165 Thanks a lot. I wonder which version of pcc you were testing with, the comments about the pcc behaviour indicate that the version used was either too old or its install was broken (pcc used to ship redundant and in practice harmful startup files, not actually being a part of the compiler). To avoid misunderstanding let me list the positive points: "Apparently, PCC doesn't support the fastcall calling convention. Nor does it issue a warning or error for the attribute that it does not understand." pcc complains/warns about unsupported attributes: $ cat a.c __attribute__((fastcall)) int fastc(int i) { return i; } $ pcc -c a.c a.c:1: warning: unsupported attribute `fastcall' $ pcc --version pcc 1.2.0.DEVEL 20141228 for i486-pc-linux-gnu This is the current version of pcc, mostly the same as the newly released pcc-1.1.0 (2014-12-10) with the reservation that I did not test the latter. "Note that it also, apparently, doesn't support shared libraries. Test cases linked against the pcc-built shared library segfault inside ld.so before reaching main." This is quite doubtless the result of using the broken startup files regrettably used to be included in the pcc-libs package. Shared libraries do work, in fact this very MUA is running shared libraries compiled with pcc. Now to the point: I tested to apply https://github.com/rth7680/libffi/commit/3fa5d70cbb18b39a5e44f1c7984dedf73446bf6c and it now passes the majority of the tests (2119) ! 306 of the still failing tests try to test FASTCALL and THISCALL which is not expected to pass. At least some of the remaining 210 ones quite probably depend on a bug in pcc which was independently discovered this week and fixed ("Float complex struct return were not dealt with as it should in the PIC case."). Moreover, at about the same time pcc seems to have got support for fastcall (!) (Nevertheless I would argue that avoiding hardcoded reliance on fastcall in libffi on x86 is good, placing less constraints on the compilers to be used with it) I am going to make the next round with the newest pcc and see how many test failures remain. Thanks again, Rune