为啥在编译 Linux 内核和 uBoot 时使用 arm-linux-gnueabi-gcc 而不是 arm-none-eabi-gcc？

Posted 2023-02-14

【中文标题】为啥在编译 Linux 内核和 uBoot 时使用 arm-linux-gnueabi-gcc 而不是 arm-none-eabi-gcc？

【英文标题】：Why arm-linux-gnueabi-gcc and not arm-none-eabi-gcc when compiling Linux kernel and uBoot?为什么在编译 Linux 内核和 uBoot 时使用 arm-linux-gnueabi-gcc 而不是 arm-none-eabi-gcc？

【发布时间】：2016-02-08 17:45:18

【问题描述】：

我有一些为 ARM cortex-m 设备以及 Linux 内核、uBoot 和 Beaglebone Black (BBB) 应用程序编译的经验（更多功能的 ARM 和 MMU，适合那些生活在岩石下的人）。对我来说，cortex-m 代码应该使用 arm-none-eabi-gcc 编译（因为没有操作系统）并且 BBB 的应用程序代码应该使用 arm-linux-gnueabi-gcc 编译（因为那里是一个操作系统，可以对其进行系统调用，并可以使用程序加载器和共享对象）。

我不明白为什么 uBoot 和内核也应该用 arm-linux-gnueabi-gcc 编译。在我看来，至少 uBoot 是一个没有花哨操作系统的裸机程序。这一直困扰着我一段时间，但我找不到答案。有没有人可以启发我？

【问题讨论】：

你从哪里学到的这个"uBoot [原文如此]，内核也应该用arm-linux-gnueabi-gcc编译"？我已经看到 U-Boot 和 Linux 内核使用相同的工具链（例如在 Buildroot 中）编译，大概是因为方便。但我通常将裸机工具链用于 U-Boot 等引导加载程序（即我构建了两个工具链）。

我只是从this 等示例中假设的。你是说uBoot实际上可以用其中任何一个编译吗？内核呢？

将 .c 编译为 .o 时，您选择的 ABI 会影响用于参数、堆栈布局等的寄存器。将 .o 链接到可执行文件时，ABI 有一个默认链接器脚本和辅助对象。但是内核和可能的 u-boot 都提供了自己的链接器脚本等，因此这一步的 ABI 并不那么重要

这个问题已经在这里得到解答：***.com/questions/38956680/…

@JoshuaDeWeese processors.ti.wiki.com EOL。链接死了。存档here。

【参考方案1】：

U-Boot 旨在尽可能地反映 Linux 的设计理念。它使用相同的配置系统、通用目录结构等。它与 Linux 共享一些 API - 请参阅 include/linux 目录。正如上面的 cmets 所提到的，此时 ABI 兼容性并不重要，但使用 Linux 编译器在哲学上对 U-Boot 来说并不是不合适的。