Re: extracting relocation info from COFF from "section contents" base d on partial_inplace

[Ian Lance Taylor <ian at wasabisystems dot com>]

"Dave Korn" <dk@artimi.com> writes:

> > While it is true that the offset
> > can be split up into the different fields, this makes relocation
> > processing harder, since it is no longer possible to treat each
> > relocation as a single unit.
> 
>   And of course there's no way to link together the related HI and LO
> part-relocations.  And then even worse it's very common in the load-long
> address synthesising sequences to find that the LO part is loaded with a
> sign-extending load... which means you can't evaluate the HI part separately
> because you don't know whether there might be a carry up from the lo part.
> And that's why there's this hideous hack in the assembler (at least some
> ports that I've seen) to put the low part of the relocation offset into the
> opcodes for *both* the _HI and _LO parts of the reloc: that way the LO part
> can just be relocated all by itself modulo 16, no problem, but the high part
> needs to have both the high and lo parts available to get it right, and the
> LO part is there in the in-place bytes and the HI part gets stuffed into the
> RELA reloc, IIUIC?
> 
> >  The issue gets even tricker when you
> > want to use part of the address computation as a common subexpression
> > which is used for two or more actual addresses.
> > 
> > That's why it's often useful to use RELA relocs for RISC chips.  It
> > wastes space, but it simplifies and speeds up the linker.
> > 
> > Ian
> 
>   IIUIC, as I said above, it isn't just simplifying: it's completely vital
> if the long load sequence uses a sign-extending load for the lo part of the
> address, isn't it?

It's not *completely* vital.  Take a look at how REFHI and REFLO are
handled in coff-mips.c.  To make this work reliably we sort the
relocations in mips_frob_file in gas/config/tc-mips.c.

Ian