Doubt about how a linker generates a memory image

Even the simplest hex output records have address fields. Google on Intel Record or Motorola S19 record document and it will be clear.

--
// richard
http://www.imagecraft.com

Hard to be sure, because you didn't tell what output format you're speaking of. But the choices usually boil down to these two:

1) some very limited-flexibility "raw binary" output format: yes, then the linker will have to pad out all the holes. You probably won't like the result if the target's address is populated as sparsely as in your example. As a possible way out of this dilemma, the linker may just generate more than one file. 2) an at least mildly flexible file format, e.g. Intel-Hex, Motorola S-Record or something along those lines. Then the linker can generate a file that effectively says: "here's stuff to go at 0x200000: (... stuff), and now here's some more that should go to 0x600000: (... more stuff)".

Formats of type 1) usually can't store even the start address of the code image, so you need some administrative procedure to make sure you still know what it was, by the time you go and load that code. That's quite obviously stupid --- it's exactly the kind of silliness computers were supposed to solve for good. The solution at hand is to put the address *in* the file, which immediately brings you to option

2), since, once the file can hold an address, it's trivial to make it capable of holding two or more.

If the IAP program loader takes a brain-dead raw file format, it'll have to be told the address (and possibly the length, too) before receiving the actual data. In case 2), which is by far the more typical case, in my experience, the information about addresses and gaps will already be part of the load file itself.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

True. There is one commercial product out and about which very cleverly reads the address of the first S-record and ignores the addresses contained in all following records! It took awhile when this one was encountered to determine why our code wasn't being loaded properly. It was many years ago, but I believe the name of the guilty party was something called VMEbug.

It seems that you're trying to use the GNU linker, ld.

The image building consists of three steps:

- combining section pieces of different modules, - assigning addresses to the combined sections, - outputting the combined memory image in selected format.

All three steps are controlled by the linker script. In embedded systems, you usually need to tailor the script to the hardware at hand. The script directs which output sections the result will have and which input sections (and from which modules) go to each output section.

The steps can be performed one-by-one: the combining can be performed by requesting relocatable output, the location is done, if it is not prohibited, and the output file format can be changed with the objcopy utility.

My preference is to do the first two steps at once, combining ELF modules into an absolutely located ELF output module. This is the recommended feed to GDB for debugging. A memory image (in Intel or Motorola hex, or even plain binary) is then extracted using objcopy.

For more information, get the GNU binutils manuals .

--

Tauno Voipio
tauno voipio (at) iki fi