please, help me with libffi on iOS porting

please, help me with libffi on iOS porting

[Guetcho Guetchev]

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?

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

This obviously happens when using the function g_object_set() with a property from Glib / Gstreamer and when that property is float / double.
So I have doubts about the code alignment. As far as I know for the ARM architectures the float / double should be strictly aligned on 4 byte boundary.
My questions here is: why the alignment of sysV.S and trampoline.S is set to 1 byte? Is there a need for that?

However when I try to change that alignment (by hacking the files that generate / patch the sources - at the end before the actual compilation the alignment is really 4 bytes (.align 2) - so I byuserpass the python scripts that apply patches and generate sources) I still get similar issue although I did not receive any warnings about the alignment of the ffi_ functions.

This is by the way using the standard automake (sat up for the cross-compilation). 

The most astonishing thing however is when I try to use xcodebuild tool.

I try the following line:

xcodebuild install -target 'libffi iOS' -configuration Debug -project libffi.xcodeproj -arch armv7 DEFAULT_COMPILER=com.apple.compilers.gcc_4.2

And the last lines of the log are these:

  setenv XCODE_VERSION_ACTUAL 0440
    setenv XCODE_VERSION_MAJOR 0400
    setenv XCODE_VERSION_MINOR 0440
    setenv YACC yacc
    /bin/sh -c "\"/Users/user/gstreamer/build/libffi/build/libffi.build/Debug-iphoneos/libffi iOS.build/Script-6C43CC3F1534FF1B00162364.sh\""

SetOwnerAndGroup "user:staff" build/UninstalledProducts/libffi.a
    cd /Users/user/gstreamer/build/libffi
    setenv PATH "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/opt/local/bin:/opt/local/sbin:/Users/user/.rvm/gems/ruby-1.9.3-p125/bin:/Users/user/.rvm/gems/ruby-1.9.3-p125@global/bin:/Users/user/.rvm/rubies/ruby-1.9.3-p125/bin:/Users/user/.rvm/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"
    /usr/sbin/chown -RH "user:staff" /Users/user/gstreamer/build/libffi/build/UninstalledProducts/libffi.a
chown: /Users/user/gstreamer/build/libffi/build/UninstalledProducts/libffi.a: No such file or directory
Command /usr/sbin/chown failed with exit code 1


** BUILD FAILED **


The following build commands failed:
	SetOwnerAndGroup "user:staff" build/UninstalledProducts/libffi.a
(1 failure)



Obviously the compilation is impossible with apple clang compiler so I had to change it with gcc 4.2. The build process completes finely. However the installation procedure fails.
Guys, have you tried the actual installation? By simply building the xcodeproj file you can't get the executables. The option "build" of xcodebuild does not produce (or at least I don't see) actual lib files). The option "install" of xcodebuild fails with some stupid chown failure on a directory UninstalledProduct which never exists. But even if I create this directory into the "build" subdirectory the result is the same. Someone messed up the environment variables for the xcodebuild.

Tried to play with almost all variables like INSTALL_PATH, DSTROOT, SKIP_INSTALL etc but the result is always the same.
And even when I created the UninstalledProducts subdirectory in build and even I touch-ed an empty file libffi.a into that (build/UninstalledProducts/) I get nothing.
Well, the installation process finishes with success but the actual length of libffi.a is set to 0 (as it was after I created it with touch command).

After exploring the scripts in build/libffi.build/Debug-iphoneos/libffi iOS.build directory (named Script-6C43CC3F1534FF1B00162364.sh and Script-6C43CC3E1534F8E200162364.sh):

Script-6C43CC3F1534FF1B00162364.sh :

#!/usr/bin/python
import subprocess
import re
import os
import errno
import sys

def main():
    with open('src/arm/trampoline.S', 'w') as tramp_out:
        p = subprocess.Popen(['bash', 'src/arm/gentramp.sh'], stdout=tramp_out)
        p.wait()

if __name__ == '__main__':
    main()


and Script-6C43CC3E1534F8E200162364.sh :

#!/bin/sh
/usr/bin/python generate-ios-source-and-headers.py


I don't get the meaning of their existence. Why are they executed as post-build steps? What are you trying to do with them?
In my opinion they should be executed prior the build phase (to patch the sources and to generate sources) but not at the final steps.


I know its kind awkward but I need libffi to be build by a script instead of opening it in Xcode and manual building procedure. 

I will be glad if I receive answers of these questions.
Thank you in advance.


FYI: Using Mac OS Mountain Lion (10.8) with Xcode 4.4.

Best regards,
Getcho

Re: please, help me with libffi on iOS porting

[Andrew Haley]

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.

Re: please, help me with libffi on iOS porting

[cowwoc]

Hi Andrew,


Andrew Haley wrote:
> 
>> 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.
> 

I believe you are wrong on this point. GNU Assembler says this:
http://sourceware.org/binutils/docs/as/ARM-Directives.html

but Apple Assembler does not:
https://developer.apple.com/library/mac/#documentation/developertools/Reference/Assembler/040-Assembler_Directives/asm_directives.html

hence the generated memory alignment is wrong.

Gili
-- 
View this message in context: http://old.nabble.com/please%2C-help-me-with-libffi-on-iOS-porting-tp34250621p34299792.html
Sent from the Sourceware - libffi-discuss mailing list archive at Nabble.com.

Re: please, help me with libffi on iOS porting

[Andrew Haley]

On 08/15/2012 03:30 AM, cowwoc wrote:
> 
> Andrew Haley wrote:
>>
>>> 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.
>>
> 
> I believe you are wrong on this point.

I'm not: that is what it says.

> GNU Assembler says this:
> http://sourceware.org/binutils/docs/as/ARM-Directives.html
> 
> but Apple Assembler does not:
> https://developer.apple.com/library/mac/#documentation/developertools/Reference/Assembler/040-Assembler_Directives/asm_directives.html
> 
> hence the generated memory alignment is wrong.

Right, so Apple's assembler is incompatible.  The align_expression
doesn't seem to be optional there, so we could simply change this to
.align 2".

Andrew.

Re: please, help me with libffi on iOS porting

[cowwoc]

Andrew Haley wrote:
> 
> On 08/15/2012 03:30 AM, cowwoc wrote:
>> 
>> Andrew Haley wrote:
>>>
>>>> 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.
>>>
>> 
>> I believe you are wrong on this point.
> 
> I'm not: that is what it says.
> 
>> GNU Assembler says this:
>> http://sourceware.org/binutils/docs/as/ARM-Directives.html
>> 
>> but Apple Assembler does not:
>> https://developer.apple.com/library/mac/#documentation/developertools/Reference/Assembler/040-Assembler_Directives/asm_directives.html
>> 
>> hence the generated memory alignment is wrong.
> 
> Right, so Apple's assembler is incompatible.  The align_expression
> doesn't seem to be optional there, so we could simply change this to
> .align 2".
> 
> Andrew.
> 

Hi Andrew,

Take a look at https://github.com/jspahrsummers/libffi. It's not my
repository but it contains lots of iOS-specific patches, including the one
for .align 2.

There is even a 4 month old pull request for this specific issue:
https://github.com/atgreen/libffi/pull/19

Gili
-- 
View this message in context: http://old.nabble.com/please%2C-help-me-with-libffi-on-iOS-porting-tp34250621p34301795.html
Sent from the Sourceware - libffi-discuss mailing list archive at Nabble.com.

Re: please, help me with libffi on iOS porting

[Andrew Haley]

On 08/15/2012 02:32 PM, cowwoc wrote:

> Take a look at https://github.com/jspahrsummers/libffi. It's not my
> repository but it contains lots of iOS-specific patches, including the one
> for .align 2.
> 
> There is even a 4 month old pull request for this specific issue:
> https://github.com/atgreen/libffi/pull/19

Hmm.  I wonder why the patches weren't submitted here.

Andrew.