-
Notifications
You must be signed in to change notification settings - Fork 5
Description
I've tried to make a minimal example to illustrate the problem, see https://git.glasklar.is/nisse/repro-tkey-link-problem, in particular the notes.txt file.
To build, checkout the repo, run git submodule update --init, make tkey-libs and make.
Since we compile with -fpic (for simplicity, everything is built with -fpic, but I expect the trigger is that lib.c is compiled with -fpic), we get a .got section in the .elf file. This is put last in the corresponding .bin file, at offset 0xe4 (loaded at address 0x400000e4), but the code doing indirection via the got uses address 0x400000e8, 4 bytes off.
In this example, the .text and .data segments get alignment 8, from use of data of type long long (I don't understand why, though. On other 32-bit archs, 64-bit values only need alignment 4). But the size of .text and .data segments are not a multiple of 8, which implies that some padding is added. As far as I can tell, this is handled correctly for direct references, including padding bytes in the .elf file, but something is messed up with .got.
I suspect .got needs some explicit handling in the linker script. Alternatively, one could maybe have the linker script fail if any .got section is present. In my tests, it has also appeared to be a work to increase the explicit ALIGN instructions in the linker script from ALIGN(4) to ALIGN(8), but not sure how that really works.
The reason I default to using -fpic also when building a static nettle library, is to avoid relocations for people that make a dynamically loaded object that is linked statically with nettle. And it would also help when building a -fpie executable (as has become popular lately) statically linked with nettle. So I don't think it's an obscure thing to do for a static library.