From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13582 invoked by alias); 3 Jan 2015 10:15:29 -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 13571 invoked by uid 89); 3 Jan 2015 10:15:28 -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 mailfe08.swip.net (HELO swip.net) (212.247.154.225) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 03 Jan 2015 10:15:26 +0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received: from [213.136.75.42] (account cxu-bx4-3f4@tele2.se HELO mail) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPSA id 563086567 for libffi-discuss@sourceware.org; Sat, 03 Jan 2015 11:15:22 +0100 Received-SPF: none receiver=mailfe08.swip.net; client-ip=213.136.75.42; envelope-from=u-xsnf@aetey.se Received: (qmail 16616 invoked from network); 3 Jan 2015 10:13:55 -0000 Received: from unknown (HELO aetey.se) (eh1ba719@127.0.0.1) by mail with ESMTPA; 3 Jan 2015 10:13:55 -0000 Date: Sat, 03 Jan 2015 10:15: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: <20150103101457.GP14316@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54A719A6.9050008@redhat.com> X-IsSubscribed: yes X-SW-Source: 2015/txt/msg00002.txt.bz2 On Fri, Jan 02, 2015 at 02:20:22PM -0800, Richard Henderson wrote: > On 01/02/2015 10:56 AM, u-xsnf@aetey.se wrote: > > Looking at the source I wonder if this has to do with the reliance > > on the fastcall attribute, which pcc does not support. > > Ah, well, that could well be. Since fastcall is a standard Windows > calling convention, I sort of assume every decent compiler supports it. > > In which case I'm going to suggest not building libffi with pcc. > An executable built with pcc should work with a library built with > gcc or clang. Oh that's too bad. As long as C code is concerned it would be a burden to build and eventually maintain either gcc or clang for the sole purpose to compile libffi. Is it hard to make libffi implementation compatible with cdecl? The calling conventions is exactly what the library is competent about. If the internal use of fastcall is desirable in certain cases, then a compile time choice between fastcall and cdecl would alleviate the problem and make one-compiler-shops with pcc (or even something else like tcc?) happy. Rune