Re: arm questions

[Ian Lance Taylor <ian@zembu.com>]

   From: hjl@lucon.org (H.J. Lu)
   Date: Thu, 15 Apr 1999 13:28:50 -0700 (PDT)

   Ok. You are saying RELA is better than REL. Does it make any senses
   to use RELA for relocatable object and allow REL for excutable and
   shared objects?

It is possible in principle.

In the general case, it is hard.  ELF permits a shared library to be
compiled normally, not PIC.  In such a case, you have to use arbitrary
relocations in the shared library.  The dynamic linker then runs into
the same addend problems as the program linker does.

For a PIC shared library, there is normally only a very restricted set
of dynamic relocs: a GOT reloc, a JMP reloc, a RELATIVE reloc, and
perhaps a few relocs in the .data section.  All of these relocs can
normally be easily represented using REL relocs.

Since in principle the dynamic linker can handle both REL and RELA
relocs in the same object, it would be possible in principle to add
this optimization for an ELF target which used RELA relocs.

I think it would probably be more immediately effective to focus
efforts on reducing the total number of dynamic relocations in libc.
For example, it has scads of RELATIVE relocs; why?  It has GLOB_DAT
and JUMP_SLOT relocs for what appear to be internal symbols; it may be
possible to eliminate these.

   >    > In the meantime, Cygnus implemented ARM ELF, using RELA relocs.
   > 
   >    Something of which we were entirely unaware of at the time, otherwise we would
   >    have attempted to collaborate in a closer fashion.
   > 
   > I now recall that I dropped the ball on this one.  I saw the request
   > for the ARM ELF work come in to Cygnus, but I didn't manage to figure
   > out that it was for a different ABI than the one in H.J.'s snapshots.
   > 

   If RELA is really desired, can ARM/Linux switch to RELA with a different
   soname? Binaries using REL should still run ok, just like what we did
   to libc 5 on x86.

If REL works now, there is probably no reason to switch to RELA.  The
only reason I can think of would be if the compiler can gain an
advantage by splitting instructions which require relocations.  It is
sometime possible to make that work with REL instructions anyhow.

It would also be possible for the linker to support REL and RELA
relocations simultaneously, so there would be no need for a big
cutover.  We would just change gas to start generating RELA
relocations, and then after a while we could throw away the REL
support.

But I don't see a reason to do that if the code works now.

Ian