This is the mail archive of the
binutils@sourceware.org
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>
Hi,
does anyone have an idea on this?
Is there any documentation which describes, which relocations have to be handled by the loader?
Regards,
Tom
binutils-owner@sourceware.org wrote:
> Von: Thomas Schmid <scth2000@yahoo.de>
> An: "binutils@sourceware.org" <binutils@sourceware.org>
> Datum: 25.07.2013 16:54
> Betreff: ld generates static relocations in shared library
> Gesendet von: binutils-owner@sourceware.org
>
> Hi,
> 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
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf
> 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;
> }