This is the mail archive of the
mailing list for the binutils project.
Re: 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: Mon, 5 Aug 2013 13:22:17 +0100 (BST)
- Subject: Re: ld generates static relocations in shared library
- References: <1375705181 dot 46694 dot YahooMailNeo at web172604 dot mail dot ir2 dot yahoo dot com>
- Reply-to: Thomas Schmid <scth2000 at yahoo dot de>
does anyone have an idea on this?
Is there any documentation which describes, which relocations have to be handled by the loader?
> Von: Thomas Schmid <firstname.lastname@example.org>
> An: "email@example.com" <firstname.lastname@example.org>
> Datum: 25.07.2013 16:54
> Betreff: ld generates static relocations in shared library
> Gesendet von: email@example.com
> 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"
> 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!
> Example code:
> extern unsigned char lpv1;
> extern unsigned char lpv2;
> unsigned char* plpv1 = &lpv1;
> void func(void)
> lpv2 = *plpv1;