RE: "relocation truncated to fit" problem

[Tao Zhang <zhangtao at cc dot gatech dot edu>]

Hi, Dave

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

Thanks a lot for the clarification, it is pretty much clear to me now. So
basically the compiler has to generate the right code, and if the branch
offset turns out too big, the linker simply complains. I tried a simple
arm program with external function calls. I found gcc generates bl for the
external calls instead of bx though. Maybe with 24 bit offset field, it is
reasonable to take chances.

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

That's a good point, thanks. Overlay command in linkscript may be a work
around to the "truncated to fit" problems. Currently, my scheme doesn't
need overlay support during linking. I just take the normal binary and
build a memory image for it in the external memory. The function calls
from the active partition in the local storage to non-active parts will be
handled by my overlay manager, which will take the original
function address, fetch the proper partition and transfer the control.
With overlaying in binary, I think a partition cannot be identified by its
address any longer, so I need to fix it up.

regards

Tao


>


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