arm 交叉编译时 gcc 的 Options

https://sourceware.org/binutils/docs/as/ARM-Options.html

https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html

 

9.4.1 Options

-mcpu=processor[+extension...]

This option specifies the target processor. The assembler will issue an error message if an attempt is made to assemble an instruction which will not execute on the target processor. The following processor names are recognized: arm1, arm2, arm250, arm3, arm6, arm60, arm600, arm610, arm620, arm7, arm7m, arm7d, arm7dm, arm7di, arm7dmi, arm70, arm700, arm700i, arm710, arm710t, arm720, arm720t, arm740t, arm710c, arm7100, arm7500, arm7500fe, arm7t, arm7tdmi, arm7tdmi-s, arm8, arm810, strongarm, strongarm1, strongarm110, strongarm1100, strongarm1110, arm9, arm920, arm920t, arm922t, arm940t, arm9tdmi, fa526 (Faraday FA526 processor), fa626 (Faraday FA626 processor), arm9e, arm926e, arm926ej-s, arm946e-r0, arm946e, arm946e-s, arm966e-r0, arm966e, arm966e-s, arm968e-s, arm10t, arm10tdmi, arm10e, arm1020, arm1020t, arm1020e, arm1022e, arm1026ej-s, fa606te (Faraday FA606TE processor), fa616te (Faraday FA616TE processor), fa626te (Faraday FA626TE processor), fmp626 (Faraday FMP626 processor), fa726te (Faraday FA726TE processor), arm1136j-s, arm1136jf-s, arm1156t2-s, arm1156t2f-s, arm1176jz-s, arm1176jzf-s, mpcore, mpcorenovfp, cortex-a5, cortex-a7, cortex-a8, cortex-a9, cortex-a15, cortex-r4, cortex-r4f, cortex-r5, cortex-r7, cortex-m4, cortex-m3, cortex-m1, cortex-m0, cortex-m0plus, ep9312 (ARM920 with Cirrus Maverick coprocessor), i80200 (Intel XScale processor) iwmmxt (Intel(r) XScale processor with Wireless MMX(tm) technology coprocessor) and xscale. The special name all may be used to allow the assembler to accept instructions valid for any ARM processor.

In addition to the basic instruction set, the assembler can be told to accept various extension mnemonics that extend the processor using the co-processor instruction space. For example, -mcpu=arm920+maverick is equivalent to specifying -mcpu=ep9312.

Multiple extensions may be specified, separated by a +. The extensions should be specified in ascending alphabetical order.

Some extensions may be restricted to particular architectures; this is documented in the list of extensions below.

Extension mnemonics may also be removed from those the assembler accepts. This is done be prepending no to the option that adds the extension. Extensions that are removed should be listed after all extensions which have been added, again in ascending alphabetical order. For example, -mcpu=ep9312+nomaverick is equivalent to specifying -mcpu=arm920.

The following extensions are currently supported: crypto (Cryptography Extensions for v8-A architecture, implies fp+simd), fp (Floating Point Extensions for v8-A architecture), idiv (Integer Divide Extensions for v7-A and v7-R architectures), iwmmxt, iwmmxt2, maverick, mp (Multiprocessing Extensions for v7-A and v7-R architectures), os (Operating System for v6M architecture), sec (Security Extensions for v6K and v7-A architectures), simd (Advanced SIMD Extensions for v8-A architecture, implies fp), virt (Virtualization Extensions for v7-A architecture, implies idiv), and xscale.

-march=architecture[+extension...]

This option specifies the target architecture. The assembler will issue an error message if an attempt is made to assemble an instruction which will not execute on the target architecture. The following architecture names are recognized: armv1, armv2, armv2a, armv2s, armv3, armv3m, armv4, armv4xm, armv4t, armv4txm, armv5, armv5t, armv5txm, armv5te, armv5texp, armv6, armv6j, armv6k, armv6z, armv6zk, armv6-m, armv6s-m, armv7, armv7-a, armv7ve, armv7-r, armv7-m, armv7e-m, armv8-a, iwmmxt and xscale. If both -mcpu and -march are specified, the assembler will use the setting for -mcpu.

The architecture option can be extended with the same instruction set extension options as the -mcpu option.

-mfpu=floating-point-format

This option specifies the floating point format to assemble for. The assembler will issue an error message if an attempt is made to assemble an instruction which will not execute on the target floating point unit. The following format options are recognized: softfpa, fpe, fpe2, fpe3, fpa, fpa10, fpa11, arm7500fe, softvfp, softvfp+vfp, vfp, vfp10, vfp10-r0, vfp9, vfpxd, vfpv2, vfpv3, vfpv3-fp16, vfpv3-d16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-d16, vfpv4, vfpv4-d16, fpv4-sp-d16, fp-armv8, arm1020t, arm1020e, arm1136jf-s, maverick, neon, neon-vfpv4, neon-fp-armv8, and crypto-neon-fp-armv8.

In addition to determining which instructions are assembled, this option also affects the way in which the .double assembler directive behaves when assembling little-endian code.

The default is dependent on the processor selected. For Architecture 5 or later, the default is to assembler for VFP instructions; for earlier architectures the default is to assemble for FPA instructions.

-mthumb

This option specifies that the assembler should start assembling Thumb instructions; that is, it should behave as though the file starts with a .code 16 directive.

-mthumb-interwork

This option specifies that the output generated by the assembler should be marked as supporting interworking.

-mimplicit-it=never

-mimplicit-it=always

-mimplicit-it=arm

-mimplicit-it=thumb

The -mimplicit-it option controls the behavior of the assembler when conditional instructions are not enclosed in IT blocks. There are four possible behaviors. If never is specified, such constructs cause a warning in ARM code and an error in Thumb-2 code. If always is specified, such constructs are accepted in both ARM and Thumb-2 code, where the IT instruction is added implicitly. If arm is specified, such constructs are accepted in ARM code and cause an error in Thumb-2 code. If thumb is specified, such constructs cause a warning in ARM code and are accepted in Thumb-2 code. If you omit this option, the behavior is equivalent to -mimplicit-it=arm.

-mapcs-26

-mapcs-32

These options specify that the output generated by the assembler should be marked as supporting the indicated version of the Arm Procedure. Calling Standard.

-matpcs

This option specifies that the output generated by the assembler should be marked as supporting the Arm/Thumb Procedure Calling Standard. If enabled this option will cause the assembler to create an empty debugging section in the object file called .arm.atpcs. Debuggers can use this to determine the ABI being used by.

-mapcs-float

This indicates the floating point variant of the APCS should be used. In this variant floating point arguments are passed in FP registers rather than integer registers.

-mapcs-reentrant

This indicates that the reentrant variant of the APCS should be used. This variant supports position independent code.

-mfloat-abi=abi

This option specifies that the output generated by the assembler should be marked as using specified floating point ABI. The following values are recognized: soft, softfp and hard.

-meabi=ver

This option specifies which EABI version the produced object files should conform to. The following values are recognized: gnu, 4 and 5.

-EB

This option specifies that the output generated by the assembler should be marked as being encoded for a big-endian processor.

-EL

This option specifies that the output generated by the assembler should be marked as being encoded for a little-endian processor.

-k

This option specifies that the output of the assembler should be marked as position-independent code (PIC).

--fix-v4bx

Allow BX instructions in ARMv4 code. This is intended for use with the linker option of the same name.

-mwarn-deprecated

-mno-warn-deprecated

Enable or disable warnings about using deprecated options or features. The default is to warn.

-mccs

Turns on CodeComposer Studio assembly syntax compatibility mode.

 

 

ndk使用硬件浮点加速的方法：

=================================

Solution:

APP_ABI := armeabi-v7a-hard

instead of

APP_ABI := armeabi-v7a

Also you can add these flags in Android.mk:

LOCAL_CXXFLAGS  := -O2 -mfpu=vfpv3-d16 -mhard-float -D_NDK_MATH_NO_SOFTFP=1 -march=armv7-a -mfloat-abi=hard
LOCAL_CFLAGS    := -O2 -mfpu=vfpv3-d16 -mhard-float -D_NDK_MATH_NO_SOFTFP=1 -march=armv7-a -mfloat-abi=hard
LOCAL_LDFLAGS   := -lm_hard

============================================

Stop the presses! The Android developers did something almost sane!

As of Android NDK revision 9c, the GCC and Clang included in the NDK can build programs for the hardware floating point ABI on ARM. This is basically a free performance boost for all floating point code.

Almost. There are some caveats that you need to be aware of. They didn’t add support for hard float by recompiling everything in user space; instead, hard float programs execute within a system that is technically soft float. What does that mean in practice?

First, to utilize the hard float ABI, you must either compile every last component of your application as hard float (the -mhard-float GCC/Clang switch), or mark individual functions with the appropriate __attribute__ to indicate the desired ABI. For example, to mark a function so that it’s called with the soft float ABI, stick __attribute__((pcs("aapcs"))) on it.

Note that the NDK will link to a libm which uses the aforementioned attribute on all of its functions. This means that if you use libm functions a lot, you’re not likely to get much of a boost in those places. The way to fix this is to add -mhard-float -D_NDK_MATH_NO_SOFTFP=1 to your GCC/Clang command line. Then add -lm_hard to your linker command line (or -Wl,-lm_hard if you just invoke GCC/Clang to link). This will make your application link statically to a libm compiled for the hard float ABI. The only downside of this is that your application will increase somewhat in size.

You will want to pass --no-warn-mismatch to the linker to silence all warnings about mixed floating point ABIs in objects. This is not ideal since it could actually be helpful in some cases, but it’s not great to see a ton of useless warnings either.

If you interact with any kind of FFI at all, such as JNI or P/Invoke, you’re in for a bad time. Due to the fact that user space is still technically soft float, VMs like Dalvik and Mono have absolutely no wayof knowing whether a native function should be invoked as soft float or hard float. Dalvik ‘solves’ this by forcing all JNI functions to use soft float (ugh). Make sure to slap JNICALL on your JNI functions so they are marked as soft float - it seems a lot of code exists that doesn’t do this, and itwill break if compiled for hard float.

Also, keep in mind that hard float (obviously) assumes the presence of an FPU. As such, it will only work on ARM v7 (armeabi-v7a in Android terms). It may work by chance on some armeabi devices, but don’t rely on that.

So what about Mono?

There’s no real story for Mono at the moment - we don’t have the liberty to force all native libraries to be recompiled with annotations to use the soft float ABI, and it would undermine the performance gain of the hard float ABI. We also have no way for users to mark native methods as soft or hard float and, besides, that would require recompiling a ton of code and adding special cases for hard float on ARM - not really acceptable for users. To make matters even worse, since the hard float support on Android isn’t a proper Android ABI (like armeabi, armeabi-v7a, mips, and x86), we can’t ask the C compiler which ABI we should be using when invoking native functions.

In short: We’re screwed.

If Mono is ever going to support hard float on Android, we need the Android developers to make it a first-class ABI, and not just a compatibility hack.

That being said, Mono does support hard float on regular Linux!

============================================