This is the mail archive of the
mailing list for the binutils project.
Re: .reloc improvement
On Sun, Aug 21, 2011 at 06:07:32AM +0100, Maciej W. Rozycki wrote:
> On Sun, 21 Aug 2011, Alan Modra wrote:
> > > > This patch makes some improvements to relocations emitted by the
> > > > .reloc directive:
> > > > 1) A symbol on these relocs is converted to section symbol plus offset
> > > > if the symbol satisifes S_IS_LOCAL and some section related
> > > > conditions. For example, forward/backward labels like "1f", and
> > > > ELF locals like .L123 will be converted. This helps keep the
> > > > symbol table tidy.
> > >
> > > Thanks for doing this. The relaxation might need to be conditional
> > > for some REL targets though.
> > Yes, it was this sort of consideration that led me to choose to only
> > substitute the section symbol for symbols that satisfy S_IS_LOCAL,
> > rather than the larger set handled by adjust_reloc_symbols. I know it
> > potentially breaks existing code, but hopefully I won't be hit by too
> > many brickbats..
> > [snip]
> > > Maybe one way would be to create a fake, temporary fixup and pass
> > > that to tc_fix_adjustable.
> > This might not be such a bad idea. If resolve_reloc_expr_symbols
> > found the frags and inserted a fake fixup in the section fixup chain,
> > then the rest of the fixup handling machinery might even work for
> > .reloc.
As I found when I started to implement this, the fly in the ointment
is that tc_fix_adjustable, md_apply_fix and so forth expect
fix->rx_r_type to be one of those BFD_RELOC_* enums, while .reloc
looks up reloc howtos. howto->type is typically the external reloc
number, and we don't have a mapping from those to a BFD_RELOC_* enum.
Even if I did build such a mapping, not all of the extern reloc
numbers have a corresponding BFD_RELOC_* enum, and not all those that
do are handled by the various backend md_apply_fix functions. :-(
> Please note that on REL MIPS targets local symbols have to be retained in
> several cases where crucial information is lost if a relocation against
> such a symbol is converted to one against the containing section's symbol.
> This applies to all the PC-relative relocations, where the relocatable
> field is too narrow to hold arbitrary addends, and also, more recently, to
> microMIPS targets, where linker relaxation has to know local symbol
> (label) addresses to perform branch displacement recalculations and to
> make the LUI/ADDIU->ADDIUPC relaxation. The latter is a linker's internal
> limitation and may possibly be lifted (possibly by using the RELA
> representation internally even on REL targets), but the former is an
> inherent problem of the object file format used.
> Just making sure these issues are not missed -- I can't have a look at
> your change at the moment and see what exact implications it has, sorry.
The implication of my change is that the programmer will need to be
careful in choosing symbols used with .reloc. While that isn't ideal,
.reloc is such a low-level interface that you need to know what you're
doing if you use it. Alternatively, I'm quite willing to disable the
symbol to section symbol conversion for REL targets.
Australia Development Lab, IBM