This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: showstopper bug on x86 (Re: libffi does not follow proper ABI on ia32)
- From: u-xsnf at aetey dot se
- To: Richard Henderson <rth at redhat dot com>
- Cc: libffi-discuss at sourceware dot org
- Date: Fri, 2 Jan 2015 19:56:53 +0100
- Subject: Re: showstopper bug on x86 (Re: libffi does not follow proper ABI on ia32)
- Authentication-results: sourceware.org; auth=none
- References: <20141222193538 dot GW14316 at example dot net> <20141224135825 dot GF14316 at example dot net> <549AEA51 dot 2000500 at redhat dot com> <54A4207F dot 9090904 at redhat dot com>
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 <ffi_closure_inner+43>
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 <ffi_closure_inner>: enter $0x30,$0x0
0xf7f49674 <ffi_closure_inner+4>: mov %ebx,-0x28(%ebp)
0xf7f49677 <ffi_closure_inner+7>: mov %esi,-0x2c(%ebp)
0xf7f4967a <ffi_closure_inner+10>: mov %edi,-0x30(%ebp)
0xf7f4967d <ffi_closure_inner+13>: call 0xf7f49682 <ffi_closure_inner+18>
0xf7f49682 <ffi_closure_inner+18>: popl -0x4(%ebp)
0xf7f49685 <ffi_closure_inner+21>: addl $0x1d9a,-0x4(%ebp)
0xf7f4968c <ffi_closure_inner+28>: mov 0xc(%ebp),%ecx
0xf7f4968f <ffi_closure_inner+31>: mov 0x8(%ebp),%eax
0xf7f49692 <ffi_closure_inner+34>: mov 0x1c(%eax),%eax
0xf7f49695 <ffi_closure_inner+37>: mov %eax,-0x8(%ebp)
0xf7f49698 <ffi_closure_inner+40>: mov -0x8(%ebp),%eax
0xf7f4969b <ffi_closure_inner+43>: mov (%eax),%eax <==== segfault
0xf7f4969d <ffi_closure_inner+45>: mov %eax,-0xc(%ebp)
0xf7f496a0 <ffi_closure_inner+48>: mov -0x8(%ebp),%eax
0xf7f496a3 <ffi_closure_inner+51>: mov 0x14(%eax),%eax
0xf7f496a6 <ffi_closure_inner+54>: mov %eax,-0x10(%ebp)
0xf7f496a9 <ffi_closure_inner+57>: movl $0x0,-0x14(%ebp)
0xf7f496b0 <ffi_closure_inner+64>: mov 0x8(%ebp),%eax
0xf7f496b3 <ffi_closure_inner+67>: 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