ld and relocatable vs. absolute

[Michael Sokolov]

Chuck Meade <chuckmeade@yahoo.com> wrote:

> Several linkers (including Diab and Green Hills) support the
> creation of a fully-linked executable image that at the same
> time retains relocation information, allowing it to be 
> relocated to a dynamically determined memory address at load
> time by an on-target loader.
>
> Such an image would not have unresolved references, it would
> just be relocatable.

I hear you very well, I have exactly the same issue on some m68k embedded
systems I work with. Basically, you'll most probably need to implement a
special feature in Binutils to do what you need for your processor / BFD
target.

This issue was first addressed in Binutils in the mid-1990s for one MIPS
embedded systems by then maintainer Ian Lance Taylor. He added an --embedded-
relocs option to ld for MIPS/ECOFF which causes the linker to create a special
section in the executable recording spots that would be interesting to a run-
time relocator. (At the same time gcc and gas had -membedded-pic options added
to them to generate embedded PIC code. Sorry, I can't tell you what they do or
why they are needed because I don't know the MIPS architecture.)

A couple months ago I implemented a similar feature (ld --embedded-relocs) for
m68k COFF (it's still on my to-do list to implement it for m68k ELF as well).
Just like the MIPS/ECOFF version it creates a section in the executable
recording spots that the run-time loader would need to relocate.

Both the MIPS/ECOFF version and the m68k version record information only about
absolute address relocations, on the assumption that these are the only ones
that need to be fixed at run time. Furthermore, they record only those
relocations that occur in the data section (.sdata for MIPS/ECOFF and .data for
m68k), but these relocations can *target* any section, and the section being
targeted is recorded. This is based on the assumption that code will reside in
ROM and data will reside in RAM. In this case one can't relocate code, only
data. Also code and data will very likely be loaded at completely different
places in the address space in this scenario, and the loader will very likely
need to know whether it's fixing a pointer to code or a pointer to data.

Another thing you could look at are the relocatable ELF shared objects.
Generally with ELF dynamic linking, executables are as fully linked as
possible, and in all instances where no dynamic linking is involved (i.e., for
all internal references) the link editor is expected to complete the link. This
works OK for executables which are not expected to be relocatable (i.e., are
expected to be loaded where specified in the program headers), but shared
objects are expected to be loaded at different addresses. The assumption is,
however, that the relative locations of all sections and segments remain the
same. Therefore, all that is needed is for the dynamic loader to add a constant
base address to all locations containing otherwise fully-linked internal
absolute addresses. In m68k ELF this is done with the special R_68K_RELATIVE
reloc, and it's generally similar for other processors. This reloc does not
involve the typical processing associated with unlinked object relocs (looking
up symbols by name, etc), and instead simply adds the base address to the
specified location.

> I would like to be able to accomplish the same with ld for
> PowerPC.  Has anyone out there done this?  Any tips?

As I don't know the PowerPC architecture or the state of its implementation in
Binutils, I can't tell you for sure whether what you want can be done with
already existing features or whether a new one would have to be added. Perhaps
other maintainers who know more about PowerPC can fill you in. If you do need
to implement a new feature, be sure to take a look at the three places I've
told you about (MIPS/ECOFF, m68k COFF/ELF, and ELF shared objects) for a
starting point on how to do this.

--
Michael Sokolov		Harhan Engineering Laboratory
Public Service Agent	International Free Computing Task Force
			International Engineering and Science Task Force
			615 N GOOD LATIMER EXPY STE #4
			DALLAS TX 75204-5852 USA

Phone: +1-214-824-7693 (Harhan Eng Lab office)
E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon)