6

我有一个产品，它使用生成“arm-elf”的编译器（gnuarm GCC 4.1.1）编译引导加载程序和应用程序。

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

该应用程序具有一项功能，可以调用引导加载程序（作为具有 2 个参数的简单 c 函数）。

我需要能够升级世界各地的现有产品，并且我可以使用始终使用相同的编译器安全地做到这一点。

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

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

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

编辑：

我认为很清楚我正在为裸机 ARM7 构建，如果它有什么不同的话......

4

3 回答 3

5

不，ABI 是使二进制文件兼容的魔法。应用程序二进制接口决定了如何与其他库/应用程序通信的各种约定。例如，ABI 将定义调用约定，它会隐含假设哪些寄存器用于将参数传递给 C 函数，以及如何处理多余的参数。

我不知道 EABI 和 ABI 之间的确切区别，但您可以通过阅读 EABI 找到其中的一些。Debian 的页面提到系统调用约定是不同的，以及一些对齐更改。

鉴于上述情况，当然，您不能混合 arm-elf 和 arm-eabi 对象。

上面的答案是在您与主应用程序中的引导加载程序代码对话的假设下给出的。鉴于接口可能非常简单（只是一个带有两个参数的函数调用），它可能会起作用。这将是一个有趣的尝试。但是，不能**保证**工作。

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

于 2012-05-03T20:36:31.630 回答
5

始终可以选择在内联汇编中调用引导加载程序，在这种情况下，您可以遵守您需要的任何调用标准:)。

但是，除了它引入的可移植性问题之外，这种方法还会对您的引导加载程序和应用程序做出两个假设：

  • 您可以在您的应用程序中检测到特定设备具有使用非 EABI 工具链构建的引导加载程序，因为您只能使用汇编代码调用旧类型的引导加载程序。
  • 您提到的两个参数被引导加载程序用作原始数据。例如，如果引导加载程序将它们用作指向结构的指针，那么您可能会面临对齐不正确、填充等问题。
于 2012-05-04T16:59:22.353 回答
2

我认为这会好起来的。我自己进行了类似的迁移，据我所知，我只遇到了与处理除法有关的问题。

这是我能找到的关于差异的最佳信息，它表明如果你没有结构对齐问题，你可能没问题。

于 2012-05-04T17:13:24.723 回答