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: Tue, 6 Jan 2015 11:21:02 +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> <20150102185653 dot GO14316 at example dot net> <54A719A6 dot 9050008 at redhat dot com> <20150103101457 dot GP14316 at example dot net> <54AB036B dot 4030104 at redhat dot com>
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