Linux supports the stdcall calling convention, either via functions
explicitly declared with the stdcall attribute, or via code compiled
with -mrtd which effectively makes stdcall the default.
This introduces FFI_STDCALL, FFI_THISCALL, and FFI_FASTCALL on
non-Windows x86-32 platforms, as non-default calling conventions.
ffi_prep_cif_core had a special case for X86_WIN32, checking for
FFI_THISCALL in addition to the FFI_FIRST_ABI-to-FFI_LAST_ABI range
before returning FFI_BAD_ABI. However, on X86_WIN32, FFI_THISCALL
already falls in that range, making the special case unnecessary.
Remove it.
code, and makes it possible to link code compiled with different
options to those used to compile libffi. For example, a
-mlong-double-128 libffi can be used with -mlong-double-64 code.
Using the return value area as a place to pass parameters wasn't such
a good idea, causing a failure of cls_ulonglong.c. I didn't see this
when running the mainline gcc libffi testsuite because that version of
the test is inferior to the upstreamm libffi test.
Using NUM_FPR_ARG_REGISTERS rather than NUM_FPR_ARG_REGISTERS64 meant
that a parameter save area could be allocated before it was strictly
necessary. Wrong but harmless. Found when splitting apart ffi.c
into 32-bit and 64-bit support.
code, and makes it possible to link code compiled with different
options to those used to compile libffi. For example, a
-mlong-double-128 libffi can be used with -mlong-double-64 code.
Using the return value area as a place to pass parameters wasn't such
a good idea, causing a failure of cls_ulonglong.c. I didn't see this
when running the mainline gcc libffi testsuite because that version of
the test is inferior to the upstreamm libffi test.
Using NUM_FPR_ARG_REGISTERS rather than NUM_FPR_ARG_REGISTERS64 meant
that a parameter save area could be allocated before it was strictly
necessary. Wrong but harmless. Found when splitting apart ffi.c
into 32-bit and 64-bit support.
linked with ELFv2 objects, so this is one case where preprocessor
tests in ffi.c are fine. Also, there is no need to define a new
FFI_ELFv2 or somesuch value in enum ffi_abi. FFI_LINUX64 will happily
serve both ABIs.
values from 2011-11-12, but in so doing reintroduced string
instructions to sysv.S that are not supported on all powerpc variants.
This patch properly copies the bounce buffer to destination in C code
rather than in asm.
I have tested this on powerpc64-linux, powerpc-linux and
powerpc-freebsd. Well, the last on powerpc-linux by lying to
configure with
CC="gcc -m32 -msvr4-struct-return -mlong-double-64" \
CXX="g++ -m32 -msvr4-struct-return -mlong-double-64" \
/src/libffi-current/configure --build=powerpc-freebsd
and then
make && make CC="gcc -m32" CXX="g++ -m32" \
RUNTESTFLAGS=--target_board=unix/-m32/-msvr4-struct-return/-mlong-double-64\
check
gcc for quite some time. Since gcc now does the correct alignment,
libffi needs to follow suit. This ought to be made selectable via
a new abi value, and the #ifdefs removed from ffi.c along with many
other #ifdefs present there and in assembly. I'll do that with a
followup patch sometime.
This is a revised version of
https://sourceware.org/ml/libffi-discuss/2013/msg00162.html
fpr area and the parameter save area, necessary when the backend
doesn't know if a function argument corresponds to the ellipsis
arguments of a variadic function. This patch adds powerpc support for
variadic functions, and changes the code to only pass fp in the ABI
mandated area. ELFv2 needs this change since the parameter save area
may not exist there.
This also fixes two faulty tests that used a non-variadic function
cast to call a variadic function, and spuriously reasoned that this is
somehow necessary for static functions..
returned values. It would be reasonable and logical to use the actual
return argument type as passed to ffi_prep_cif, but this would mean
changing a large number of tests that use ffi_arg and all backends
that write results to an ffi_arg.
