我可以将arm-eabi与arm-elf混合使用吗?

时间:2012-05-03 19:33:53

标签: gcc embedded arm eabi

我有一个产品,使用编译器(gnuarm GCC 4.1.1)编译bootloader和应用程序,生成“arm-elf”。

引导加载程序和应用程序在链接描述文件的不同FLASH内存区域中隔离。

该应用程序具有一个功能,使其能够调用引导加载程序(作为一个带有2个参数的简单c函数)。

我需要能够升级世界各地的现有产品,并且我可以使用相同的编译器安全地完成此操作。

现在我希望能够使用输出arm-eabi的新GCC版本来编译此产品应用程序。

对于新产品,一切都会好的,其中应用程序和引导程序都使用相同的工具链进行编译,但现有产品会发生什么? 如果我使用GCC 4.6.x和arm-none-eabi编译一个新的应用程序,我的应用程序是否仍然能够从旧的arm-elf引导程序中调用引导加载程序功能?


此外,与上述问题没有直接关系,我可以将使用arm-elf编译的目标文件混合到用arm-eabi编译的二进制文件中吗?


编辑:

我认为很清楚我正在构建裸机ARM7,如果它有任何区别......

3 个答案:

答案 0 :(得分:5)

没有。 ABI是使二进制兼容的神奇之处。应用程序二进制接口确定了有关如何与其他库/应用程序通信的各种约定。例如,ABI将定义调用约定,它对诸如哪些寄存器用于将参数传递给C函数以及如何处理多余参数之类的事情做出隐式假设。

我不知道EABI和ABI之间的确切差异,但您可以通过阅读EABI找到其中一些。 Debian's page提到系统调用约定不同,以及一些对齐更改。

鉴于上述情况,当然,你不能混合使用arm-elf和arm-eabi物体。

上面的答案是假设您在主应用程序中与引导加载程序代码进行通信。鉴于接口可能非常简单(只是带有两个参数的函数调用),它可能会起作用。尝试这是一个有趣的实验。但是,它不能保证**工作。

请记住,您不必使用EABI。您可以使用gcc 4.6以及旧版本生成arm-elf工具链。由于您在Windows上使用二进制工具链,因此您可能面临更多挑战。我建议调查crosstool-ng,它在Linux上运行得很好,并且可以在cygwin上正常工作以构建适当的工具链。

答案 1 :(得分:4)

总是可以选择在内联汇编中调用bootloader,在这种情况下,您可以遵循所需的任何调用标准:)。

然而,除了它引入的可移植性问题之外,这种方法还会对引导加载程序和应用程序做出两个假设:

  • 您可以在应用中检测到某个特定设备具有使用非EABI工具链构建的引导加载程序,因为您只能使用汇编代码调用旧类型的引导加载程序。
  • 您提到的两个参数被引导加载程序用作原始数据。如果引导加载程序使用它们,例如,作为结构的指针,那么您可能会遇到错误对齐,填充等问题。

答案 2 :(得分:2)

认为这样就行了。我自己做了这样的迁移,从我记忆中我只遇到了处理分工的问题。

This is the best info I can find about the differences,它表明如果你没有结构对齐问题,你可能没问题。