作者:HerbertYuan 邮箱
发布时间:2017-9-17 站点:Inside Linux Development

What is the differences between “arm-none-eabi-” and “arm-linux-gnueabihf”? Can I use “arm-linux-gnueabihf” tool chain in bare-metal environment? How do you know which toolchain binary to use where?

The general form of compiler/linker prefix is as follows:



C has values which seem odd until you understand the history behind it (basically AArch32 used to have a linux-gnu ABI which got changed so needed a new name so we have linux-gnueabi). For AArch32 we have linux-gnueabi and linux-gnueabihf which indicate soft float, and hard float respectively.

The bare-metal ABI will assume a different C library (newlib for example, or even no C library) to the Linux ABI (which assumes glibc). Therefore, the compiler may make different function calls depending on what it believes is available above and beyond the Standard C library.

Also the bare-metal ABI and Linux ABI for the 32-bit Instruction sets make different assumptions about the storage size of enums and wchar_t which you have to be careful of (not a complete list). And the difference between the 32-bit and 64-bit ABIs are also numerous and subtle (the obvious example being pointer sizes).

EABI is the new Application Binary Interface (ABI) specification for the ARM Architecture introduced in 2005. It aims to provide interoperability between binaries compiled by various compilers like codesourcery, ADS, RVCT, RVDS, etc. Which previous non-EABI binaries couldn’t provide. Thus, It is possible to link libraries created using different compilers with EABI support but old ABI libraries lacked that compatibility.

This caused a lot of trouble to me recently. I compiled the linux kernel with EABI turned off. Then I compiled busybox and other libraries using arm-none-linux-gnueabi target as dynamically shared libraries. The kernel won’t load the rootfs built using EABI toolchain. It used to print,

Kernel panic – not syncing: Attempted to kill init!

I downloaded another toolchain(arm-linux target this time) and compiled the rootfs using it. This time, kernel had no trouble loading the file system. As I searched further, I learned that EABI and non-EABI are not inter-operable and hence the mess. I also learned that all the toolchain supplied by codesourcery since 2005 are EABI based. The arm-linux toolchain I downloaded recently(which is non-EABI) is not from codesourcery.

Copyright © 2017-2021. Some Rights Reserved.