This is the mail archive of the
mailing list for the binutils project.
ld generates static relocations in shared library
- From: Thomas Schmid <scth2000 at yahoo dot de>
- To: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Thu, 25 Jul 2013 15:53:48 +0100 (BST)
- Subject: ld generates static relocations in shared library
- Reply-to: Thomas Schmid <scth2000 at yahoo dot de>
I have a question concerning the relocations generated by the linker:
If I compile the example code at the bottom with
arm-elf-gcc init.c -o lib.so -Wl,-shared -nostdlib
I get a shared library with some relocations (readelf lib.so -r):
0000032c 00000d02 R_ARM_ABS32 000004b8 plpv1
00000330 00001302 R_ARM_ABS32 00000000 lpv2
000004b8 00000b02 R_ARM_ABS32 00000000 lpv1
Till now I believed, that the linker resolves all static relocations and generates dynamic relocations (to be handled by the loader), where it is necessary.
Why are there static relocations left in the linker output?
The document "ELF for the ARM Architecture" at
says, R_ARM_ABS32 is a static relocation and also:
> Static relocations are processed by a static linker; they are normally either fully resolved or used to produce dynamic relocations
> for processing by a post-linking step or a dynamic loader. A well formed image will have no static relocations after static linking
> is complete, so a post-linker or dynamic loader will normally only haveto deal with dynamic relocations.
BTW, this can also be reproduced using i386-elf-gcc, the static relocation used there is R_386_32.
Can anyone tell me, why and tell me, which relocations should really be handled in the loader?
In the meantime, I was told to use the option "-fPIC" - which in fact doesn't help, also after that a static relocation (R_ARM_ABS32) is left in the library.
Thanks in advance!
extern unsigned char lpv1;
extern unsigned char lpv2;
unsigned char* plpv1 = &lpv1;
lpv2 = *plpv1;