arm-elf和arm-eabi的区别

文章链接:http://embdev.net/topic/129737

我是从这个链接中看到的。觉得有点意思。因为自己用交叉编译器编译的时候。会出现arm-elf,arm-none-eabi,arm-eabi这些选择,倒底它们有什么区别呢?

what is difference between arm-elf and arm-eabi?


Author: Martin Thomas (mthomas) (Moderator)
Posted on:

Dan Miller wrote:
> I've been trying, for a couple of days, to build the project which was
> associated with the Embedded.com articles "Building Bare-Metal ARM
> Systems with GNU".  I've been hoping that this will clarify alot of the
> confusion that I've experienced in trying to convert an existing project
> from IAR to gnuarm.
As far as I know the code from the embedded.com tutorial has been tested
with a Codesourcery G++ package (the lite version is free, Codesourcery
gets paid by ARM to improve the GNU tools AFAIK). So maybe this is the
package that should be used to avoid further confusion. Once you have
some basic knowledge of the tools you will see that it is not that
difficult to adapt the code for other GNU-precompiled-packages or
to/from other compilers.

> As it turns out, after three weeks of research,
Three weeks? - Uff.

> I have at least four
> different versions of GNUARM on my system:
> 1. gnuarm (arm-elf)
> 2. winarm (arm-elf) (slightly earlier version than gnuarm)
> 3. Ride (arm-none-eabi)
> 4. Sarm (arm-eabi)
gnuarm (I expect this is a package from gnuarm.org) and "older" versions
of WinARM are very similar. Main differences: WinARM has been created
for "non-cygwin" hosts and uses a slightly different newlib
configuration.

EABI and "old" ABI are different "targets" for which the GNU toolchain
can be build. EABI has been created as a common binary interface so
object code and libraries created with one toolchain/compiler can linked
to a project created with another one. Search on www.arm.com for further
details.

> Ultimately, only ONE of these four packages could actually build the
> project - Ride's arm-none-eabi.
It is well possible that the "Ride binaries" are very similar or even a
copy of the Codesourcery package. So this might be the reason why the
Quantum example-code can be build with this tools without problems.
Until gcc 4.3.0 the Codesourcery package has been the only one which
offered Cortex-M3 support and AFAIK Ride supports STM32 too. Just
speculation, I have never used the Ride tools. I don't know "Sarm" so I
can not comment on it at all.

> All others would fail in different
> ways.
You did not write the error-messages created during the attempts with
the other packages so it's difficult to analyze the reason why they
failed.

If would be interesting to see the error-messages when you try to build
with DevkitARM R23 or WinARM test-version 20080831.

> What's interesting, though, is that the output of the project,
> using arm-none-eabi, is a .elf file!!!
The file-extension is not important. elf and axf are just the usual
extensions. Just look into the makefile. Why "!!!"? What did you expect?

> So... what is the difference between arm-elf, arm-none-eabi, and
> arm-eabi ???
arm-elf is usually the prefix for GNU toolchains created for the arm-elf
target, arm-none-eabi for the target arm-eabi. But this does not mean
much since one can set the prefix when building the toolchain. At least
eabi should be an indicator that the toolchain has been created for
target arm-eabi.

>Obviously, the "none" in arm-none-eabi does not mean
> no-elf ...
This might be wrong. As far as I know it means "no operating-system" on
the target (for "bare metal") compared to for example arm-linux-elf.

I do understand your confusion, so stay with the GNU package that works
for you to get started. Once you know a little bit about the usage of
the GNU tools you will see that the differences are small and porting
code between them is rather easy.
Porting code from IAR to GNU is a more difficult esp. if the EWARM
compiler-extension have been used.

Author: Spencer Oliver (ntfreak)
Posted on:

>
>> Ultimately, only ONE of these four packages could actually build the
>> project - Ride's arm-none-eabi.
> It is well possible that the "Ride binaries" are very similar or even a
> copy of the Codesourcery package. So this might be the reason why the
> Quantum example-code can be build with this tools without problems.
> Until gcc 4.3.0 the Codesourcery package has been the only one which
> offered Cortex-M3 support and AFAIK Ride supports STM32 too. Just
> speculation, I have never used the Ride tools. I don't know "Sarm" so I
> can not comment on it at all.
>

I can tell you ride use the codesoucery toolchain as delivered.
sarm is the toolchain delivered with Anglia IDEaliST, it is based on
codesoucery but has a few tweaks with newlib.

Cheers
Spen

上面得出了一个结论,arm-elf是GNU的编译工具链。如果你要用arm-eabi的话,最好用newlib这个库。
但是我用newlib库太郁闷了,甚至没有ioctl的操作,所以还是用glibc吧。

相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页