j4x*_*j4x 6 embedded gcc 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构建,如果它有任何区别......
不是.ABI是使二进制兼容的神奇之处.应用程序二进制接口确定了有关如何与其他库/应用程序通信的各种约定.例如,ABI将定义调用约定,它对诸如哪些寄存器用于将参数传递给C函数以及如何处理多余参数之类的事情做出隐式假设.
我不知道EABI和ABI之间的确切差异,但你可以通过阅读EABI找到其中的一些.Debian的页面提到系统调用约定不同,以及一些对齐更改.
当然,鉴于上述情况,你不能混合arm-elf和arm-eabi对象.
上面的答案是假设您与主应用程序中的引导加载程序代码进行通信.鉴于接口可能非常简单(只是带有两个参数的函数调用),它可能会起作用.尝试这是一个有趣的实验.然而,它不能保证**工作.
请记住,您不必使用EABI.您可以使用gcc 4.6以及旧版本生成arm-elf工具链.由于您在Windows上使用二进制工具链,因此您可能面临更多挑战.我建议调查一下在Linux上运行得很好的crosstool-ng,并且可以在cygwin上正常工作来构建合适的工具链.
小智 5
始终可以选择在内联汇编中调用引导加载程序，在这种情况下，您可以遵循您需要的任何调用标准:)。
但是，除了它引入的可移植性问题之外，这种方法还会对引导加载程序和应用程序做出两个假设：