[Bug ld/16163] New: ld generates static relocations in shared library

[scth2000 at yahoo dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=16163

            Bug ID: 16163
           Summary: ld generates static relocations in shared library
           Product: binutils
           Version: unspecified
            Status: NEW
          Severity: minor
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: scth2000 at yahoo dot de

Hi,
I have a problem 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.

Example code:

    extern unsigned char lpv1;
    extern unsigned char lpv2;

    unsigned char* plpv1 = &lpv1;

    void func(void)
    {
        lpv2 = *plpv1;
    }

I got a first answer on that from the binutils mailing list from Nick Clifton:

> Hi Thomas,
> > 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
> 
> Yes - this is correct...
> 
> >> >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,
> 
> Right - but libso.so is not a fully linked binary.  It is a shared
> library that is going to be used as part of another static link operation.
> 
> For example:
> 
>   % cat main.c
>   extern void func (void);
>   extern int printf (const char *, ...);
> 
>   unsigned char lpv1, lpv2;
> 
>   int main (void)
>   {
>     lpv1 = 1;
>     lpv2 = 2;
> 
>     func ();
> 
>     return printf ("lpv1 = %d lpv2 = %d\n", lpv1, lpv2);
>   }
> 
>   % arm-elf-gcc main.c -L. lib.so
> 
>   % readelf -r a,out
>   Relocation section '.rel.plt' at offset 0x8220 contains 5 entries:
>     Offset    Info    Type            Sym.Value  Sym. Name
>   0001a984  00000216 R_ARM_JUMP_SLOT  00000000  malloc
>   0001a988  00000416 R_ARM_JUMP_SLOT  00000000  __deregister_frame_inf
>   0001a98c  00000916 R_ARM_JUMP_SLOT  0000828c  func
>   0001a990  00000e16 R_ARM_JUMP_SLOT  00000000  __register_frame_info
>   0001a994  00001016 R_ARM_JUMP_SLOT  00000000  free
> 
> 
> So now all of the static relocations have been resolved and only dynamic
> relocations remain.
> 
> Cheers
>   Nick

Ok, on the one hand, libso.so is used at static link-time of an executable, as
described here.
But on the other hand, libso.so is installed (=loaded) as dynamic library on
the target - and that's the point I don't understand:
What shall the loader do with this static relocations?
Which static relocations can occur in a shared library and must be handled by
the loader ?

Regards,
Tom

-- 
You are receiving this mail because:
You are on the CC list for the bug.