Re: Link-time call sizing and section stretching

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

   Date: Thu, 6 Jan 00 19:49:39 -0600
   From: msokolov@meson.jpsystems.com (Michael Sokolov)

   I'm using COFF only as an intermediate format and the
   "executable" produced by ld isn't actually executed on anything, but is fed
   into a program that rips the raw section images out of it and blasts them into
   ROM. I know that folks tend to prefer ELF to COFF these days. However, ELF
   stands for Executable and Linkable Format, and almost all of its fancy features
   not present in COFF have to do with the executable part and UNIX ABIs and
   shared libraries. These features are of no use for an intermediate format and
   would be just dead weight, which is why I think COFF is a better choice.

The main advantage of ELF over COFF in an embedded system is that ELF
permits the section alignment to set on a section by section basis.

   However, there is a high overhead associated with
   them, which makes it very important to use 16-bit references wherever possible
   and use 32-bit ones only where necessary

This general class of problem is what the GNU linker calls relaxation.
Relaxation is implemented for a number of targets: SH, H8/300,
MIPS/ECOFF with -membedded-pic come to mind.

The solutions more or less follow the lines you sketched out: keep all
the relocations in assembler output, and then hack over them in the
linker.

The most interesting one to you might be the MIPS -membedded-pic work,
since it has some similar characteristics.  The MIPS only has a 18 bit
relative branch.  A call to a procedure which is more than 18 bits
away is changed to a 5 instruction sequence.  The linker relaxation
code is in bfd/coff-mips.c.

   As far as I could tell, what I'm describing is doable. However, my binutils
   hacking skills are probably a little insufficient for a hack like this.
   Therefore, I would very much appreciate any suggestions and help. The
   impression I've got from looking at the binutils code is that this is something
   that a hacker more GNU-literate than I am would be able to do in a timeframe
   from a few hours to a few days. Since this is not a hobby of mine but something
   that our company needs for our projects, and we need it urgently, I'm sure we
   would be able to pay someone for a couple of days of work for this (I'm Cc'ing
   this posting to our management for that).

Frankly, I think your time estimates are low.  I've done this sort of
relaxation work for a number of processors in BFD already, and I've
done very similar work for the m68000 using another linker.  However,
if I were to do this (which I will not), I would estimate the work at
closer to a couple of weeks.

Good luck, though.

Ian