Re: showstopper bug on x86 (Re: libffi does not follow proper ABI on ia32)

[u-xsnf@aetey.se]

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