AEABI compliance
The IAR build tools for Arm support the Embedded Application Binary Interface for Arm, AEABI, defined by Arm Limited. This interface is based on the Intel IA64 ABI interface. The advantage of adhering to AEABI is that any such module can be linked with any other AEABI-compliant module, even modules produced by tools provided by other vendors.
The IAR build tools for Arm support the following parts of the AEABI:
Procedure Call Standard for the 32-bit Arm architecture | |
C++ ABI for the 32-bit Arm architecture | |
ELF for the 32-bit Arm architecture | |
DWARF for the 32-bit Arm architecture | |
Runtime ABI for the 32-bit Arm architecture | |
C library ABI for the 32-bit Arm architecture | |
Procedure Call Standard for the 64-bit Arm architecture | |
Vector function application binary interface specification for the 64-bit Arm architecture | |
ELF for the 64-bit Arm architecture | |
DWARF for the 64-bit Arm architecture | |
C++ ABI for the 64-bit Arm architecture |
The IAR build tools only support a bare metal platform, that is a ROM-based system that lacks an explicit operating system.
Note:
The AEABI is specified for C89 only
The AEABI does not specify C++ library compatibility
Neither the size of an
enumor ofwchar_tis constant in the AEABI.64-bit Arm has no runtime ABI or a C ABI. Therefore, the compiler option
‑‑aeabihas no effect in 64-bit mode.
If AEABI compliance is enabled, certain preprocessor constants become real constant variables instead.
Linking AEABI-compliant modules using the IAR ILINK linker
When building an application using the IAR ILINK Linker, the following types of modules can be combined:
Modules produced using IAR build tools, both AEABI-compliant modules as well as modules that are not AEABI-compliant
AEABI-compliant modules produced using build tools from another vendor.
Note
To link a module produced by a compiler from another vendor, extra support libraries from that vendor might be required.
The IAR ILINK Linker automatically chooses the appropriate standard C/C++ libraries to use based on attributes from the object files. Imported object files might not have all these attributes. Therefore, you might need to help ILINK choose the standard library by verifying one or more of the following details:
Include at least one module built with the IAR C/C++ Compiler for Arm.
The used CPU by specifying the
‑‑cpulinker optionIf full I/O is needed, make sure to link with a Full library configuration in the standard library
Potential incompatibilities include but are not limited to:
The size of
enumThe size of
wchar_tThe calling convention
The instruction set used.
When linking AEABI-compliant modules, also consider the information in the chapters Linking using ILINK and Linking your application.
Linking AEABI-compliant modules using a third-party linker
If you have a module produced using the IAR C/C++ Compiler and you plan to link that module using a linker from a different vendor, that module must be AEABI-compliant, see Enabling AEABI compliance in the compiler.
In addition, if that module uses any of the IAR-specific compiler extensions, you must make sure that those features are also supported by the tools from the other vendor. Note specifically:
Support for the following extensions must be verified:
#pragma pack,__no_init,__root, and__ramfuncThe following extensions are harmless to use:
#pragma location/@,__arm,__thumb,__svc,__irq,__fiq, and__nested.
Enabling AEABI compliance in the compiler
You can enable AEABI compliance in the compiler by setting the ‑‑aeabi option. In this case, you must also use the ‑‑guard_calls option.
Caution
In the IDE, use the Project>Options>C/C++ Compiler>Extra Options page to specify the ‑‑aeabi and ‑‑guard_calls options.
Danger
On the command line, use the options ‑‑aeabi and ‑‑guard_calls to enable AEABI support in the compiler.
Alternatively, to enable support for AEABI for a specific system header file, you must define the preprocessor symbol _AEABI_PORTABILITY_LEVEL to non-zero prior to including a system header file, and make sure that the symbol AEABI_PORTABLE is set to non-zero after the inclusion of the header file:
#define _AEABI_PORTABILITY_LEVEL 1 #undef _AEABI_PORTABLE #include <header.h> #ifndef _AEABI_PORTABLE #error "header.h not AEABI compatible" #endif