我有一个产品，使用编译器（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，如果它有任何区别......
3 回答
不是.ABI是使二进制兼容的神奇之处 . 应用程序二进制接口确定了有关如何与其他库/应用程序通信的各种约定 . 例如，ABI将定义调用约定，它对诸如哪些寄存器用于将参数传递给C函数以及如何处理多余参数之类的事情做出隐式假设 .
我不知道EABI和ABI之间的确切差异，但你可以通过阅读EABI找到其中的一些 . Debian's page提到系统调用约定不同，以及一些对齐更改 .
当然，鉴于上述情况，你不能混合arm-elf和arm-eabi对象 .
上面的答案是假设您与主应用程序中的引导加载程序代码进行通信 . 鉴于接口可能非常简单（只是带有两个参数的函数调用），它可能会起作用 . 尝试这是一个有趣的实验 . 但是，它不能保证**工作 .
请记住，您不必使用EABI . 您可以使用gcc 4.6以及旧版本生成arm-elf工具链 . 因为你建议调查crosstool-ng，它在Linux上工作得很好，并且可以在cygwin上正常工作以构建适当的工具链 .
总是可以选择在内联汇编中调用bootloader，在这种情况下，您可以遵循所需的任何调用标准:) .
但是，除了它引入的可移植性问题之外，这种方法还会对引导加载程序和应用程序做出两个假设：
您可以在应用中检测到特定设备具有使用非EABI工具链构建的引导加载程序，因为您只能使用汇编代码调用旧类型的引导加载程序 .
您提到的两个参数被引导加载程序用作原始数据 . 如果引导加载程序使用它们，例如，作为结构的指针，那么您可能会遇到错误对齐，填充等问题 .
我认为这样会好的 . 我自己做了这样的迁移，从我记忆中我只遇到了处理分工的问题 .
This is the best info I can find about the differences，它表明如果你没有结构对齐问题，你可能没问题 .