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

[u-xsnf@aetey.se]

Hello Richard,

On Mon, Jan 05, 2015 at 01:34:35PM -0800, Richard Henderson wrote:
> On 01/03/2015 02:14 AM, u-xsnf@aetey.se wrote:
> > Is it hard to make libffi implementation compatible with cdecl?
> > The calling conventions is exactly what the library is competent about. 
> 
> I guess it wasn't that hard.
> 
> See https://github.com/atgreen/libffi/pull/165

Thanks a lot.

I wonder which version of pcc you were testing with, the comments
about the pcc behaviour indicate that the version used was either
too old or its install was broken (pcc used to ship redundant and
in practice harmful startup files, not actually being a part of the compiler).

To avoid misunderstanding let me list the positive points:

"Apparently, PCC doesn't support the fastcall calling convention.
Nor does it issue a warning or error for the attribute that it
does not understand."

pcc complains/warns about unsupported attributes:

$ cat a.c
__attribute__((fastcall)) int fastc(int i) {
  return i;
}
$ pcc -c a.c
a.c:1: warning: unsupported attribute `fastcall'
$ pcc --version
pcc 1.2.0.DEVEL 20141228 for i486-pc-linux-gnu

This is the current version of pcc, mostly the same as the newly released
pcc-1.1.0 (2014-12-10) with the reservation that I did not test the latter.

"Note that it also, apparently, doesn't support shared libraries. Test
cases linked against the pcc-built shared library segfault inside ld.so
before reaching main."

This is quite doubtless the result of using the broken startup files
regrettably used to be included in the pcc-libs package.
Shared libraries do work, in fact this very MUA is running shared
libraries compiled with pcc.

Now to the point:

I tested to apply
 https://github.com/rth7680/libffi/commit/3fa5d70cbb18b39a5e44f1c7984dedf73446bf6c

and it now passes the majority of the tests (2119) !

306 of the still failing tests try to test FASTCALL and THISCALL which
is not expected to pass. At least some of the remaining 210 ones quite
probably depend on a bug in pcc which was independently discovered this
week and fixed ("Float complex struct return were not dealt with as it
should in the PIC case.").

Moreover, at about the same time pcc seems to have got support for fastcall (!)

(Nevertheless I would argue that avoiding hardcoded reliance on fastcall
in libffi on x86 is good, placing less constraints on the compilers to
be used with it)

I am going to make the next round with the newest pcc and see how many
test failures remain.

Thanks again,
Rune