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: extracting relocation info from COFF from "section contents" base d on partial_inplace


> -----Original Message-----
> From: Ian Lance Taylor
> Sent: 08 April 2004 18:48
> To: Dave Korn

> "Dave Korn" <dk@artimi.com> writes:
> 
> Although this explanation was generally very good, I want to note one
> thing.
> 
> >   Get it?  The instruction contains a field that is big 
> enough to contain
> > the offset (it has to be, since the final result of 
> symbol+offset is going
> > to be stored into there), so why not use that field to 
> store the offset in
> > the relocatable .o files and save space in the relocation 
> structures?
> 
> Many RISC chips can not represent a complete address in a single
> instruction, and instead build it using arithmetic operations.  In
> that case there may be several fields involved, and the offset may be
> too large to fit in any one of them. 

  Yeh, I was skating over a detail there.

> 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?


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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