This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Never emit R_ARM_PC24 relocations when linking
On Thu, Jan 08, 2004 at 10:29:27AM +0000, Richard Earnshaw wrote:
> > 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
> case
> - 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.
Well, this patch does two things:
- eliminating PC24 dynamic relocations when building a shared
library. This is a nice result because of the PIC benefits,
although of course you can still generate non-PIC data references.
This was a secondary goal, because I didn't want to teach a
dynamic linker about R_ARM_THM_PLT22 for carelessly built libraries.
- eliminating the difference between PC24 and PLT32 input
relocations. This was my original goal, for exactly the first
reason above - I didn't want to add an R_ARM_THM_PLT22.
This will let you eliminate R_ARM_PLT32 from the linker's input
(i.e. the assembler's output) should you want to.
> 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?
I think so. I was working under the assumption that there were no
objections to Philip Blundell's message on eabi AT handhelds DOT org,
but I understand that that's not the proper forum for the discussion.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer