Currently, due to the absence of a 64-bit port for Darwin PPC, the libffi suffers massive failures on that architecture at -m64... === libffi Summary for unix/-m32 === # of expected passes 1068 # of expected failures 8 # of unsupported tests 8 === libffi Summary for unix/-m64 === # of expected passes 472 # of unexpected failures 384 # of expected failures 8 # of unsupported tests 8 === libffi Summary === # of expected passes 1540 # of unexpected failures 384 # of expected failures 16 # of unsupported tests 16
*** Bug 29181 has been marked as a duplicate of this bug. ***
For the 64-bit Darwin PPC port of libffi you have to follow the 64-bit calling conventions: http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/index.html Also, take a look at src/powerpc/ffi.c on how it is done for linux ppc 32 vs. 64-bit. It does not help to make the 32-bit port compilable with -m64. You need to write the 64-bit part!
*** Bug 30134 has been marked as a duplicate of this bug. ***
Andreas, Can't we duplicate the existing code in darwin.S, darwin_closure.S, ffi_darwin.c and sysv.S and wrapper it with a test for __powerpc64__ as a starting point. I think if we at least get discussion going about what needs changed we might slowly progress this PR. Looking at... http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Articles/32bitPowerPC.html#//apple_ref/doc/uid/TP40002438 http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Articles/64bitPowerPC.html#//apple_ref/doc/uid/TP40002471 I see that in the Size and natural alignment of the scalar data types table the main differences between 32-bit and 64-bit are... 32-bit 64-bit Bool 4 1 unsigned long 4 8 signed long 4 8 pointer 4 8 Parameter area to general-purpose register mapping 32-bit 64-bit GPR3 SP+24 SP+48 GPR4 SP+28 SP+56 GPR5 SP+32 SP+64 GPR6 SP+36 SP+72 GRP7 SP+40 SP+80 GPR8 SP+44 SP+88 GPR9 SP+48 SP+96 GPR10 SP+52 SP+104
Jack, you can try, but I think it is a bit wasted time. Well, depends on how long the process takes to get the patches from apple. [wolfram:gcc/head/objdir] andreast% file /usr/lib/libffi.dylib /usr/lib/libffi.dylib: Mach-O universal binary with 4 architectures /usr/lib/libffi.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc /usr/lib/libffi.dylib (for architecture ppc64): Mach-O 64-bit dynamically linked shared library ppc64 /usr/lib/libffi.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/lib/libffi.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 I will not spend any time on this issue except help out merging and testing. But as I do not have an own ppc64 I will only have limited interest atm. Maybe you understand...
libffi is even more broken on powerpc-apple-darwin9 than on powerpc-apple-darwin8: === libffi Summary for unix/-m64 === # of expected passes 412 # of unexpected failures 412 # of unsupported tests 8 === libffi Summary === # of expected passes 1520 # of unexpected failures 416 # of unsupported tests 16 Is fixing it only an "enhancement"?
Fixed by the patch in http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00804.html.
Author: iains Date: Sat Dec 18 08:56:46 2010 New Revision: 168016 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168016 Log: libffi: PR libffi/29152 PR libffi/42378 * src/powerpc/darwin_closure.S: Provide Darwin64 implementation, update comments. * src/powerpc/ffitarget.h (POWERPC_DARWIN64): New, (FFI_TRAMPOLINE_SIZE): Update for Darwin64. * src/powerpc/darwin.S: Provide Darwin64 implementation, update comments. * src/powerpc/ffi_darwin.c: Likewise. Modified: trunk/libffi/ChangeLog trunk/libffi/src/powerpc/darwin.S trunk/libffi/src/powerpc/darwin_closure.S trunk/libffi/src/powerpc/ffi_darwin.c trunk/libffi/src/powerpc/ffitarget.h
The libffi testsuite shows no regressions with -m64 at r168608 on powerpc-apple-darwin9. Closing as fixed.