Re: libffi fails to build on powerpc64-linux

[Peter Bergner <bergner at vnet dot ibm dot com>]

Removing Kyle from the CC list, since his email address doesn't seem to
be valid anymore and adding Andreas since his patch from 2009 mentioned
below triggers the assert.



On Tue, 2012-03-06 at 09:34 -0600, Peter Bergner wrote:


> Doing a build on one of my old POWER5 systems with a gcc that
> defaults to producing 32-bit binaries, I'm seeing the following
> testsuite failures:
> 
> Running /home/bergner/src/libffi-src/testsuite/libffi.call/call.exp ...
> FAIL: libffi.call/many.c -O0 -W -Wall execution test
> FAIL: libffi.call/many.c -O2 execution test
> FAIL: libffi.call/many.c -O3 execution test
> FAIL: libffi.call/many.c -Os execution test
> FAIL: libffi.call/many.c -O2 -fomit-frame-pointer execution test
> Running /home/bergner/src/libffi-src/testsuite/libffi.special/special.exp ...
> 
> 		=== libffi Summary ===
> 
> # of expected passes		1654
> # of unexpected failures	5
> # of unsupported tests		55
> 
> I'll debug those to try and find out what is happening.

The many.c test case tests the calling of a function with 13 float
formal arguments (and zero integer arguments).  This test fails due
to us hitting an assert in ffi_prep_args_SYSV():

  FFI_ASSERT (flags & FLAG_4_GPR_ARGUMENTS || intarg_count <= 4);

In this case flags does not have the FLAG_4_GPR_ARGUMENTS bit set because
ffi_prep_cif_machdep() computed that there were zero integer arguments.
However, ffi_prep_args_SYSV() somehow thinks there are 5 integer arguments
due to this code:

        case FFI_TYPE_FLOAT:
          /* With FFI_LINUX_SOFT_FLOAT floats are handled like UINT32.  */
          double_tmp = **p_argv.f;
          if (fparg_count >= NUM_FPR_ARG_REGISTERS)
            {
              *next_arg.f = (float) double_tmp;
              next_arg.u += 1;
              intarg_count++;
            }
          else
            ...

At first, I thought this was an obvious counting error, but looking at
when that code was added, Andreas said it was to fix a ppc32 bug:

  http://sourceware.org/ml/libffi-discuss/2009/msg00360.html

Does anyone remember exactly how/why that fixed the bug?  Looking at
the use of intarg_count in ffi_prep_args_SYSV(), it looks like it is
used solely for determining the alignment of arguments that are passed
on the stack and not specifically for actually counting the actual
number of integer register arguments which the assert is assuming.
Should we just remove that assert (I tried that and the test case
now passes) or should we try and be more strict about when it is
incremented and computing the stack alignment for args differently?


Peter