From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6106 invoked by alias); 12 Jun 2014 20:54:43 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 6095 invoked by uid 89); 12 Jun 2014 20:54:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RDNS_DYNAMIC autolearn=no version=3.3.2 X-HELO: ds.vvi.com Received: from 173-167-71-114-centralpennsylvania.hfc.comcastbusiness.net (HELO ds.vvi.com) (173.167.71.114) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Jun 2014 20:54:41 +0000 Received: from localhost (localhost [127.0.0.1]) by ds.vvi.com (Postfix) with ESMTP id 571CE45C1C7; Thu, 12 Jun 2014 16:54:39 -0400 (EDT) Received: from ds.vvi.com ([127.0.0.1]) by localhost (ds.vvi.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oX2b9ZV5VTbA; Thu, 12 Jun 2014 16:54:37 -0400 (EDT) Received: from [192.168.1.4] (unknown [192.168.1.4]) by ds.vvi.com (Postfix) with ESMTPSA id 095A045C1BA; Thu, 12 Jun 2014 16:54:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: libffi-3.1 on iOS From: Ed VanVliet In-Reply-To: <87tx7qz99y.fsf@moxielogic.com> Date: Thu, 12 Jun 2014 20:54:00 -0000 Cc: libffi-discuss@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <91973BED-C7E1-4FF2-B76C-A9A5B8D3768D@vvi.com> References: <78ECC115-FDDC-493D-8E2B-00745978E522@vvi.com> <87tx7qz99y.fsf@moxielogic.com> To: Anthony Green X-SW-Source: 2014/txt/msg00069.txt.bz2 Dear AG, On Jun 12, 2014, at 6:56 AM, Anthony Green wrote: > Ed VanVliet writes: >=20 >> Running libffi on iOS (iPhone) simulator works for both 32 and 64 bit si= mulators using libffi-3.0.14-rc0 >>=20 >> But, with libffi-3.1 it works for 64 bit simulator, but fails to link fo= r 32 bit simulator; giving the following: >>=20 >> (null): "_ffi_call_win32", referenced from: >> (null): "_ffi_closure_FASTCALL", referenced from: >> (null): "_ffi_closure_STDCALL", referenced from: >> (null): "_ffi_closure_THISCALL", referenced from: >> (null): Linker command failed with exit code 1 (use -v to see >> invocation) >=20 > Could you please try adding win32.S to src_files for > simulator64_platform in generate-darwin-source-and-headers.py and > rebuilding? The problem is in the 32 bit simulator, not the 64 bit simulator; and only = when the .a archived is linked into a (nonrelocatable) application binary. = Putting that into simulator64_platform makes no difference (it works both w= ays). Taking it out of simulator_platform does not solve the problem. >> On the ARM target the linker gives the following warnings: >>=20 >> ld: warning: arm64 function not 4-byte aligned: ltmp0 from /libffi.a(sys= v_arm64.o) >> ld: warning: arm64 function not 4-byte aligned: _ffi_call_SYSV from /lib= ffi.a(sysv_arm64.o) >> ld: warning: arm64 function not 4-byte aligned: _ffi_closure_SYSV from /= libffi.a(sysv_arm64.o) >>=20 >> which also do not seem to cause a problem. >>=20 >> It would be nice to fix the build and code so it didn't produce the >> error and warnings. >=20 > So this is weird. ffi_call_SYSV and ffi_closure_SYSV both have... >=20 > #ifdef __APPLE__ > .align 2 > #endif >=20 > ...which I believe should make things 4-byte aligned. Is __APPLE__ not d= efined? __APPLE__ is defined during compilation of sysv_arm64.S Sincerely, Ed