我可以混合手臂吗？
我有一个产品，其引导程序和应用程序使用编译器（gnuarm GCC 4.1.1）编译生成“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的页面提到系统调用约定是不同的，以及一些对齐方式的变化。
鉴于上述情况，当然，你不能混合胳膊精灵和胳膊eabi物体。
假设您在主应用程序中与引导加载程序代码进行通信，则给出上述答案。 鉴于接口可能非常简单（只是带有两个参数的函数调用），它可能会工作。 这将是一个有趣的尝试。 但是，它不是**保证**工作。
请记住，您不必使用EABI。 您可以使用gcc 4.6以及旧版本生成一个arm-elf工具链。 由于您在Windows上使用二进制工具链，因此您可能会面临更多挑战。 我建议您研究一下crosstool-ng，它在Linux上运行得非常好，并且可以在cygwin上运行以构建适当的工具链。
总是可以选择在内联汇编中调用引导加载程序，在这种情况下，您可以遵循任何您需要的调用标准:)。
但是，除了它引入的可移植性问题之外，这种方法还将对您的引导加载程序和应用程序做出两个假设：
我认为这将是确定的。 我自己做了这样的迁移，从我记得我只遇到了一个处理分裂的问题。
这是我可以找到有关差异的最佳信息，它表明，如果您没有结构对齐问题，那么您可能没问题。
链接地址: http://www.djcxy.com/p/86921.html上一篇: Can I mix arm