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: Sat, 3 Jan 2015 11:14:57 +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>
On Fri, Jan 02, 2015 at 02:20:22PM -0800, Richard Henderson wrote:
> On 01/02/2015 10:56 AM, u-xsnf@aetey.se wrote:
> > Looking at the source I wonder if this has to do with the reliance
> > on the fastcall attribute, which pcc does not support.
>
> Ah, well, that could well be. Since fastcall is a standard Windows
> calling convention, I sort of assume every decent compiler supports it.
>
> In which case I'm going to suggest not building libffi with pcc.
> An executable built with pcc should work with a library built with
> gcc or clang.
Oh that's too bad.
As long as C code is concerned it would be a burden to build and
eventually maintain either gcc or clang for the sole purpose to compile
libffi.
Is it hard to make libffi implementation compatible with cdecl?
The calling conventions is exactly what the library is competent about.
If the internal use of fastcall is desirable in certain cases, then
a compile time choice between fastcall and cdecl would alleviate the
problem and make one-compiler-shops with pcc (or even something else
like tcc?) happy.
Rune