Never emit R_ARM_PC24 relocations when linking
Thu Jan 8 10:30:00 GMT 2004
> Right now we have a lot of baggage carried around for the difference between
> R_ARM_PLT32 relocations and R_ARM_PC24. In particular, we emit R_ARM_PC24
> relocations for shared libraries when we receive R_ARM_PC24 input
> relocations. This seems like a misfeature; every branch instruction should
> either be resolved locally, or go through a PLT stub.
> So, as someone (either Philip Blundell or Richard Earnshaw) suggested to me
> last year, this patch removes the special handling of R_ARM_PC24
> relocations. At final_link_relocate time, we reference the PLT entry iff
> one was created; while plt.refcount can be inaccurate for whether one is
> really needed, once we've converted to plt.offset the decision has been
> made. A consequence of this means that pc_count is no longer needed; it is
> subsumed by plt.refcount.
> Incidentally I remove an incorrect comment - ".long foo - ." will not
> produce an R_ARM_PC24 relocation. The only way to get one is with a branch.
> Tested via make check for targets arm-elf and arm-linux, and a complete
> rebuild of world. It took me a couple tries to hammer out the bugs glibc
> turned up. OK?
I'm a little bit confused by your message. Yes, we do want to eliminate
the differences between the PC24 and PLT32 relocs, because once correctly
implemented there is no difference between the two. However, the
consequence of this is that the PLT32 reloc is clearly redundant -- it
says nothing that the PC24 reloc doesn't already say. So it seems to me
that we should be moving towards eliminating the PLT32 reloc, not the
other way around.
The advantages of all this, of course, are:
- It works equally for Thumb without the need to add more relocs for that
- It works correctly if non-pic code is dropped into a shared library
- We can drop the need to annotate branch instructions in PIC assembly
with (PLT), something that irritates folks writing in assembler.
However, if I understand your message correctly, that isn't really what
this patch is about. It's really about the DYNAMIC relocs that we emit as
a result of building a shared library.
The AEABI forum hasn't really got as far as discussing the SVR4 dynamic
model yet (it's one of the things I'd like to get to this quarter if
possible), so this patch is probably jumping the gun a little bit.
However, I suspect that we are likely to want to keep the JUMP_SLOT
dynamic reloc in preference to the PC24 dynamic reloc -- to do otherwise
would most likely cause too much upheaval for existing dynamic linkers.
Have I understood you correctly?
More information about the Binutils