RE: "relocation truncated to fit" problem

["Dave Korn" <dk at artimi dot com>]

> -----Original Message-----
> From: binutils-owner On Behalf Of Tao Zhang
> Sent: 29 June 2004 05:22

> Hi, all

  Hello!
 
> I am working on a processor with very limited local storage. 
> I am trying
> to run a program bigger than local storage in the processor, using the
> similiar mechanism to overlaying. Currently, I cannot even 
> compile the big
> program, due to "relocation truncated to fit" errors.
> 
> I understand the problem, but I am not sure how to solve it. If a
> branch target offset is too large for an architecture, the 
> branch has to
> be transformed to an indirect one. The problem is among 
> compiler, assembler
> and linker, who should take care of the problem? Does the 
> compiler have to be
> aware of the exact offset of the branch? It may be possible 
> if the target
> is inside the same compilation unit, but for external definitions
> (relocations in the object files), compiler surely doesn't 
> have an idea,
> so how can it make a right decision on using relative branch 
> or indirect
> branch?? Should this problem be taken care by the linker? 
> Then what kind
> of branch compiler should generate first? Can the linker 
> transform a relative
> branch to an indirect one? I am quite confused about how the toolchain
> works together and make this working. Could somebody explain it to me?


  Right, well there are two issues here.

  The thing about branches being too large for the opcode field is, as you
say, usually solved by using indirection.  If you take a look at e.g. the
arm or ppc backends of gcc, and look for the words 'longcall', you'll see
that the compiler employs a heuristic that anything in the same compilation
unit can definitely be reached by a local branch and anything outside it is
reached by an indirect jump through a register because that's at least
guaranteed to be safe.

  The linker can do clever things like changing code sequences for indirect
references into short branches based on the relative distance in the final
linked output, but in the general case it doesn't.  Look up 'relaxing' in
the ld/bfd documentation: these sorts of tricks are target-specific, and
most ports don't implement much by the way of relaxation.  But IIRC the m68k
port will relax long branches to short ones.

  However, if you're using an overlaying technique, then you surely
shouldn't be trying to link your program as one big object at all.  It seems
to me that if your program is bigger than the entire memory space, no kind
of indirect jump is going to be able to help you there!

  Don't you just want to keep the object files for each of the overlay
modules separate, and use the linker to do a final (non-relocatable) link on
each one separately to relocate them all to the same base address in memory
which will be the address of the area you're going to load the overlays into
and execute them from at runtime?


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