This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]