This was originally reported on the Python tracker:
httpa://bugs.python.org/issue23958
The original patch was written by Steve R. Hastings.
I've updated it to current master of libffi.
Add a new calling convention FFI_EFI64, alias FFI_WIN64, on all X86_64
platforms. This allows libffi compiled on a 64-bit x86 platform to call
EFI functions.
Compile in ffiw64.c and win64.S on all X86_64 platforms. When compiled
for a platform other than X86_WIN64, ffiw64.c suffixes its functions
with _efi64, to avoid conflict with the platform's actual
implementations of those functions.
Declare a local variable to match the type of the struct field assigned
to it, rather than adding unsigned to the type. Fixes a -Wpointer-sign
warning.
Non-WIN64 versions of the GNU assembler don't support the .seh_*
directives for structured exception handling, so wrap them in a macro
that compiles to nothing.
Handle the registers used for the non-Windows x86-64 calling convention
when on a non-Windows platform. Distinguish between cases that should
refer to the native argument registers (defined as arg0, arg1, arg2, and
arg3) and cases that should always refer to the Windows argument
registers.
* Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
uses in src/x86/{sysv, unix64}.S, as on Darwin.
* Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
generated .eh_frame sections match, otherwise libffi.so fails to link:
* Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
the moment.
EHFrame{N} IIRC is a special cue to ld64 that it should treat the unwind
in the object as "special/legacy" .. [these days everything is .cfi_xxxx
(except, cctools-as, as you noted)] .. without that much confusion arises
with ld64's atom-isation of the eh_frame section.
xxxx.eh labels are not needed for darwin ld64 >= 85.2.1 (i.e. darwin9,
xcode 3.1.4) to all intents and purposes, that's all that matters now,
since I think that anyone trying to build on 10.4/darwin8/xcode2.5 would
have to use a later ld64 (from odcctools) for other reasons.
The unwind info isn't 100% correct at all points during the epilogue,
and not annotating is just as incorrect as the annotation. This works
better on systems that do not support DW_OP_call_frame_cfa.
Darwin aligns long-double to 16, and thus all of the long double
tests were failing due to not honoring that. We ought to be able
to devise a test case for GCC using __attribute__((aligned)) that
would have failed too.
The Apple assembler defaults to power of two alignment, rather than
byte alignment like everyone else. Force byte alignment by using
the proper directive.
Since libffi currently doesn't allow empty structures, libgo
currently maps them to ffi_type_void. Given that we'll abort
on this case, handle it gracefully.
Move everything into sysv.S, removing win32.S and freebsd.S.
Handle all abis with a single ffi_closure_inner function.
Move complexity of the raw THISCALL trampoline into assembly
instead of the trampoline itself.
Only push the context for the REGISTER abi; let the rest
receive it in a register.
Decouple the assembly from FFI_TYPE_*. Merge prep_args with ffi_call,
passing the frame and the stack to the assembly.
Note that this patch isn't really standalone, as this breaks closures.
The x86_64 unix port only handles one ABI; don't define all of the
other symbols. The UNIX64 symbol retains the same value.
The i386 ports ought to have the same symbols, even if we can't yet
unify the values without incrementing the libffi soname.
Dumps all of the hand-coded unwind info for gas generated. Move jump
table data into .rodata. Adjust ffi_call_unix64 to load the static
chain. Split out sse portions of ffi_closure_unix64 to
ffi_closure_unix64_sse rather than test cif->flags at runtime.
