From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28044 invoked by alias); 2 Jan 2015 18:57: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 28034 invoked by uid 89); 2 Jan 2015 18:57:27 -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 mailfe05.swip.net (HELO swip.net) (212.247.154.129) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 Jan 2015 18:57:23 +0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received: from [82.165.137.178] (account cxu-bx4-3f4@tele2.se HELO mail) by mailfe05.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPSA id 557290053 for libffi-discuss@sourceware.org; Fri, 02 Jan 2015 19:57:18 +0100 Received-SPF: none receiver=mailfe05.swip.net; client-ip=82.165.137.178; envelope-from=u-xsnf@aetey.se Received: (qmail 13321 invoked from network); 2 Jan 2015 18:55:52 -0000 Received: from unknown (HELO aetey.se) (eh1ba719@127.0.0.1) by mail with ESMTPA; 2 Jan 2015 18:55:52 -0000 Date: Fri, 02 Jan 2015 18:57: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: <20150102185653.GO14316@example.net> References: <20141222193538.GW14316@example.net> <20141224135825.GF14316@example.net> <549AEA51.2000500@redhat.com> <54A4207F.9090904@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54A4207F.9090904@redhat.com> X-IsSubscribed: yes X-SW-Source: 2015/txt/msg00000.txt.bz2 Hello Richard, Thanks for coming back on the New Year's Eve! On Wed, Dec 31, 2014 at 08:12:47AM -0800, Richard Henderson wrote: > On 12/24/2014 08:31 AM, Richard Henderson wrote: > > On 12/24/2014 05:58 AM, u-xsnf@aetey.se wrote: > >> Nevertheless I would appreciate at least hints about the prospect to fix > >> this bug (apparently non-conformant C ABI of libffi on x86 Linux), > >> which presumably went unnoticed for a long time due to gcc not exercising > >> the full ABI. > > > > Yes, I see the problem. Fixing it may have to wait until the new year. > > Please try the branch > > git://github.com/rth7680/libffi.git pcc I was able to compile it and the behaviour is different now, unfortunately getting a segfault anyway, in a different place: ------------------- === libffi Summary === # of expected passes 870 # of unexpected failures 1265 ------------------- Below is some gdb data for the first failing test: (gdb) run Starting program: /[....]/i486-pc-linux-gnu/testsuite/closure_fn0.exe (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. 0xf7f4969b in ffi_closure_inner () from ../.libs/libffi.so.6 (gdb) bt #0 0xf7f4969b in ffi_closure_inner () from ../.libs/libffi.so.6 #1 0xf7f49cfe in ffi_closure_i386 () from ../.libs/libffi.so.6 #2 0x080488e6 in main () (gdb) info reg eax 0xfa831e74 -92070284 ecx 0x0 0 edx 0xffffd738 -10440 ebx 0xf7f4b41c -134958052 esp 0xffffd6d0 0xffffd6d0 ebp 0xffffd700 0xffffd700 esi 0xf7ffb8b0 -134235984 edi 0x4 4 eip 0xf7f4969b 0xf7f4969b eflags 0x10282 [ SF IF RF ] cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x63 99 (gdb) x/20i ffi_closure_inner 0xf7f49670 : enter $0x30,$0x0 0xf7f49674 : mov %ebx,-0x28(%ebp) 0xf7f49677 : mov %esi,-0x2c(%ebp) 0xf7f4967a : mov %edi,-0x30(%ebp) 0xf7f4967d : call 0xf7f49682 0xf7f49682 : popl -0x4(%ebp) 0xf7f49685 : addl $0x1d9a,-0x4(%ebp) 0xf7f4968c : mov 0xc(%ebp),%ecx 0xf7f4968f : mov 0x8(%ebp),%eax 0xf7f49692 : mov 0x1c(%eax),%eax 0xf7f49695 : mov %eax,-0x8(%ebp) 0xf7f49698 : mov -0x8(%ebp),%eax 0xf7f4969b : mov (%eax),%eax <==== segfault 0xf7f4969d : mov %eax,-0xc(%ebp) 0xf7f496a0 : mov -0x8(%ebp),%eax 0xf7f496a3 : mov 0x14(%eax),%eax 0xf7f496a6 : mov %eax,-0x10(%ebp) 0xf7f496a9 : movl $0x0,-0x14(%ebp) 0xf7f496b0 : mov 0x8(%ebp),%eax 0xf7f496b3 : mov %eax,-0x18(%ebp) Looking at the source I wonder if this has to do with the reliance on the fastcall attribute, which pcc does not support. Hope this helps for making another iteration. Rune