Doubt about how a linker generates a memory image

Hi everyone,

I am confused about how the linker actually goes about generating a
memory image. Right now im studying how ld works, i have to use it with
an ARM920T.

Suppose i have a program with two sections, one of which has a size of
1kb, and is to be placed at location 0x200000, and another which also
has a size of 1kb and is to be placed at 0x600000. How does the linke
ensure that these sections go to the correct place? Does it do this by
padding the intermediate spaces? But if this were true, then for a 2kb
program, the size of the image would be 0x600000 + 1Kb!

When the image is loaded into the uC`s memory through, say, a serial
connection, the loading program would be dumb and would not know where
to place which part of the image..so how does the data get to the
correct place??

Plz help..

Regards

Mayank

Mayank Kaushik wrote:

>When the image is loaded into the uC`s memory through, say, a serial
>connection, the loading program would be dumb and would not know where
>to place which part of the image..so how does the data get to the
>correct place??
>  
>
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

Mayank Kaushik <prehistorictoad2k@yahoo.com> wrote:

> Suppose i have a program with two sections, one of which has a size of
> 1kb, and is to be placed at location 0x200000, and another which also
> has a size of 1kb and is to be placed at 0x600000. How does the linke
> ensure that these sections go to the correct place? 

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.

> When the image is loaded into the uC`s memory through, say, a serial
> connection, the loading program would be dumb and would not know
> where to place which part of the image..so how does the data get to
> the correct place??

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.

Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> writes:
> 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.

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.

Mayank Kaushik wrote:
> Hi everyone,
> 
> I am confused about how the linker actually goes about generating a
> memory image. Right now im studying how ld works, i have to use it with
> an ARM920T.
> 
> Suppose i have a program with two sections, one of which has a size of
> 1kb, and is to be placed at location 0x200000, and another which also
> has a size of 1kb and is to be placed at 0x600000. How does the linke
> ensure that these sections go to the correct place? Does it do this by
> padding the intermediate spaces? But if this were true, then for a 2kb
> program, the size of the image would be 0x600000 + 1Kb!
> 
> When the image is loaded into the uC`s memory through, say, a serial
> connection, the loading program would be dumb and would not know where
> to place which part of the image..so how does the data get to the
> correct place??
> 

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
<http://www.gnu.org/>.

-- 

Tauno Voipio
tauno voipio (at) iki fi