我在我的OMAP3 目标上使用u-boot-2011.12，交叉工具链是CodeSourcery arm-none-linux-gnueabi，我编译了u-boot，将它下载到目标上并启动它，一切正常，但我有一些问题关于u-boot重定位功能，我们知道这个功能是基于PIC（位置无关代码），位置无关代码是通过将-fpic标志设置为gcc来生成的，但是我没有找到@987654330 @ 在编译标志中。没有PIC，u-boot如何实现重定位功能？
【问题讨论】：
标签： gcc arm beagleboard relocation u-boot
请记住，当 u-boot 运行时，还没有操作系统。它并不真正需要大多数用户应用程序中使用的“图片”功能。我将在下面描述的是 PowerPC 架构。
u-boot 最初在 NV 内存（NAND 或 NOR）中运行。在 u-boot 初始化大多数外围设备（特别是 RAM）后，它会定位到 RAM 的顶部，为全局数据保留一些区域，然后将自身复制到 RAM。然后，u-boot 将跳转到 RAM 中的代码并修改修复程序。 u-boot 现在重新定位在 RAM 中。
查看您的架构的 start.S 文件并找到 relocate_code() 函数。然后学习，学习，学习......
【讨论】：
我也觉得这很麻烦，并在这个问题上纠结了几个小时。
幸运的是，我在 u-boot 邮件列表中偶然发现了以下主题：
http://lists.denx.de/pipermail/u-boot/2010-October/078297.html
这就是说，至少在 ARM 上，不需要在编译时使用 -fPIC/-fPIE 来生成与位置无关的二进制文件。它通过尽可能多地预先完成工作来简化运行时加载程序的任务，但仅此而已。
无论您是否使用 fPIC，您始终可以在 LINK TIME 使用 -pic / -pie，这会将所有与位置相关的引用移动到重定位部分。由于在 COMPILE TIME 未执行任何处理来添加帮助程序，因此预计此部分会比使用 -fPIC 时更大。
他们得出结论，就他们的目的而言，使用 -fPIC 与仅链接时间的解决方案相比没有任何显着优势。
[编辑] 请参阅提交 u-boot 92d5ecba 以供参考
arm：实现 ELF 重定位 http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=92d5ecba47feb9961c3b7525e947866c5f0d2de5
【讨论】：