From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29176 invoked by alias); 6 Aug 2012 08:55:47 -0000 Received: (qmail 29168 invoked by uid 22791); 6 Aug 2012 08:55:46 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,TW_BF,TW_CP,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 06 Aug 2012 08:55:31 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q768tUiF011452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Aug 2012 04:55:30 -0400 Received: from zebedee.pink (ovpn-113-128.phx2.redhat.com [10.3.113.128]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q768tSVL024615; Mon, 6 Aug 2012 04:55:29 -0400 Message-ID: <501F867F.50301@redhat.com> Date: Mon, 06 Aug 2012 08:55:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Guetcho Guetchev CC: "libffi-discuss@sourceware.org" Subject: Re: please, help me with libffi on iOS porting References: <32A33156-EC2B-47FF-B3F9-43558704FA6C@gmail.com> In-Reply-To: <32A33156-EC2B-47FF-B3F9-43558704FA6C@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2012/txt/msg00222.txt.bz2 On 08/03/2012 01:01 PM, Guetcho Guetchev wrote: > Hello guys, > I am trying to port Glib and Gstreamer for iOS. > Recently I encountered several issues related to the code alignment. > First of all I get the following warnings when compiling Glib or whatever library depending on libffi: > > ld: warning: ARM function not 4-byte aligned: _ffi_call_SYSV from /Users/user/gstreamer/lib/libffi.a(sysv.o) > ld: warning: ARM function not 4-byte aligned: .ffi_call_SYSV_end from /Users/user/gstreamer/lib/libffi.a(sysv.o) > ld: warning: ARM function not 4-byte aligned: _ffi_closure_SYSV from /Users/user/gstreamer/lib/libffi.a(sysv.o) > ld: warning: ARM function not 4-byte aligned: .Lclosure_epilogue from /Users/user/gstreamer/lib/libffi.a(sysv.o) > ld: warning: ARM function not 4-byte aligned: .Lretint from /Users/user/gstreamer/lib/libffi.a(sysv.o) > ld: warning: ARM function not 4-byte aligned: .Lretlonglong from /Users/user/gstreamer/lib/libffi.a(sysv.o) > ld: warning: ARM function not 4-byte aligned: .ffi_closure_SYSV_end from /Users/user/gstreamer/lib/libffi.a(sysv.o) > ld: warning: ARM function not 4-byte aligned: _ffi_arm_trampoline from /Users/user/gstreamer/lib/libffi.a(sysv.o) > > When I dug into the code I found that on several files (sysV.s and > trampoline.S along with several patches / fixes that are applied to > these files ) where the code alignment is set to 1 byte (.align > 0). However the default alignment for gcc / clang compilers is 4 > bytes. As far as I know for the thumb ARM assembly it is preferable > to have 4 bytes alignment. So is there a reason the alignment is > set to 1 byte? The doc says: `.align EXPRESSION [, EXPRESSION]' This is the generic .ALIGN directive. For the ARM however if the first argument is zero (ie no alignment is needed) the assembler will behave as if the argument had been 2 (ie pad to the next four byte boundary). This is for compatibility with ARM's own assembler. > But the next issue is worse: > In ffi_call() I get an assert at line 260: > > 247: switch (cif->abi) > 248: { > 249: case FFI_SYSV: > 250: ffi_call_SYSV (fn, &ecif, cif->bytes, cif->flags, ecif.rvalue); > 251: break; > 252: > 253: case FFI_VFP: > 254: #ifdef __ARM_EABI__ > 255: ffi_call_VFP (fn, &ecif, cif->bytes, cif->flags, ecif.rvalue); > 256: break; > 257: #endif > 258: > 259: default: > 260: FFI_ASSERT(0); > 261: break; > 262: } > 263: if (small_struct) > 264: memcpy (rvalue, &temp, cif->rtype->size); > 265: else if (vfp_struct) > 266: memcpy (rvalue, ecif.rvalue, cif->rtype->size); > 267: } > > > the value of cfi->abi is FFI_VFP So, you're using hard float arg passing, but not EABI? How can this be? Hard-float requires EABI. Andrew.