英文:
libc and libgcc in PIC
问题
在一些需要完全位置独立的固件代码上工作。已经设置好了我的构建系统,以及一些初始的固件代码,它在运行时修复了GOT到正确的地址。我能够链接libgcc和libc,但它不能正常工作。
一些函数能够正常工作,比如memcpy
,但utoa
没有正确地引用digits
字符串。问题的根本原因似乎是库是使用fPIC编译的(因此基地址为零)。
是否有一种方法可以将共享库中的符号添加到GOT中?
我在Debian上使用arm-none-eabi-gcc,目标是ARM v7。
英文:
Working on some firmware code that needs to be completely position independent. Already have my build system set up, and some initial firmware code that fixes the GOT to the right addresses at runtime. I'm able to link in libgcc and libc, but it doesn't work properly.
Some functions work, like memcpy
, but utoa
doesn't correctly reference the digits
string. Root cause of the problem seems to be that the libs are compiled without fPIC (so base address is zero).
Is there a way to add symbols from the shared library to the GOT?
I'm using arm-none-eabi-gcc on Debian, targeting an ARM v7.
答案1
得分: 1
需要重新编译libc.a
和libm.a
以支持PIC。您可以使用-v
标志查询您的gcc以获取具体信息。通常,这将生成一个构建记录。例如,我使用的是gcc-arm-none-eabi-9-2019-q4,可以在Launchpad上找到构建日志和使用的精确libc
存储库。以下是由STM32CubeIDE使用的另一个存储库。
https://launchpad.net/gcc-arm-embedded/10.0/10.3-2021.10
您需要使用-fPIE -mno-pic-data-is-text-relative
和--with-pic
,并按照原始选项保留其他库的构建选项。CFLAGS_FOR_TARGET
可以用来覆盖默认设置。我使用了-mno-pic-data-is-text-relative
;我的系统具有绝对数据,但PIC代码。看来gcc不支持此选项。因此,我不得不牺牲r9
,它始终相同。
newlib
可能托管在git://sourceware.org/git/newlib-cygwin.git。
如果编译器以PIC多库的方式生成将是很好的。但遗憾的是,它们目前不是。
是否有办法将共享库中的符号添加到GOT(全局偏移表)中?
当然。您需要使用PIC/PIE选项进行编译,否则库将没有GOT条目。此外,您需要编写自己的链接脚本。只需确保将库对象包括在GOT部分中。我将我的库对象添加到.data
部分中。
/* 全局偏移允许对数据进行重定位。 */
_got_address = .;
*(.got)
*(.got*)
_got_end = .;
您可以使用adr
和ldr
来执行重定位。
/* 重定位GOT表的闪存地址到运行时 */
got_update:
/* 运行时地址修复。 */
adr r0, got_update /* 运行时。 */
ldr r1, =got_update /* 链接时。 */
因此,'GOT'偏移是r0,r1之间的差异。如果GOT目标位于闪存中,我添加了偏移量。但您需要的重定位取决于您的系统。
我使用了静态库,我猜这是您作为支持"空白金属"应用程序的意图,支持"空中"类型更新。在这种情况下,代码可以从NOR/QSPI闪存的多个位置运行。有一个关于静态链接的共享库的问题,它可能还使用了PIC机制,并且比我上面描述的复杂得多。在这种情况下,代码可能是通用的,但数据是分离的。
英文:
You will need to recompile libc.a and libm.a to support PIC. You can query your gcc with '-v' to get the specifics. Often this will lead to a build record. For example, I have gcc-arm-none-eabi-9-2019-q4 which leads to launchpad and you can find the build logs and exact libc repo used. Here is another used by the STM32CubeIDE.
https://launchpad.net/gcc-arm-embedded/10.0/10.3-2021.10
You will need '-fPIE -mno-pic-data-is-text-relative' and '--with-pic' and leave the other libraries build options as per the original. The 'CFLAGS_FOR_TARGET' can be used to over-ride the defaults. I use '-mno-pic-data-is-text-relative'; My system had absolute data, but PIC code. It seems gcc does not support this option. So, I had to sacrifice r9
which is always the same.
The newlib is likely hosted at git://sourceware.org/git/newlib-cygwin.git.
It would be nice if the compilers were produced with a PIC multi-lib. Alas, they are not currently.
> Is there a way to add symbols from the shared library to the GOT?
Sure. You need to compile with PIC/PIE options, or the libraries will not have GOT entries. Also, you need to write your own linker script. Just be sure to include the library objects in the GOT section as well. I added mine to the .data
section.
/* Global offset allows relocation of data. */
_got_address = .;
*(.got)
*(.got*)
_got_end = .;
You can use adr
and ldr
to perform relocations.
/* Relocate got table flash address to runtime */
got_update:
/* Fixup for runtime address. */
adr r0, got_update /* Run time. */
ldr r1, =got_update /* Link time. */
So, the 'GOT' offset is the difference between r0,r1. If the GOT target was in flash, I added the offset. But what relocations you need will depend on your system.
I used static libraries, which I guess is your intent as a 'bare metal' application that supports 'over the air' type updates. In this case, the code can run from multiple locations in NOR/QSPI flash. There is Q/A on statically linked shared libraries, which might also use PIC mechanics and is much more complex than what I describe above. For this case, the code might be common, but the data is seperate.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论