1. Home
  2. Embedded Programming
  3. linking and loading images

linking and loading images

Hi,

I would like to have your suggestions on how to achieve the following in the simplest, cleanest way.

I have images A and B (and possibly C, D, ... ) to be loaded in physical memory one after the other. Each have .text, .data, .bss sections. B should be linked at the next page after A ends (so it must know where A ends at its link time), also the code in A, should be able to know/discover where B is going to be loaded and where it ends at its runtime.

My possible solutions:

1) If I build A and B as separate images, by first building and linking A, the page at which B would start (i.e. the next page after A) can be determined. I can easily filter objdump output for A to find out where it ends, and include B's start address in B's linker script before building it. But I have already built A, so there's the problem of patching A's image to insert B's start and end address somewhere, and this might be tedious.

2) I could link the two together using a single linker script. Then where each image is loaded would be determined at link time, and each image can be aware of where the other is, by simply reading linker-defined variables. The problem with this is these are actually two different images, objects in them have no relation, also each needs to have its own _start address, so that will probably be ambiguous. Furthermore, I may need to have images C, D and more. So it would quickly get tedious to maintain a single linker script for multiple images meant to be independent.

3) After all images are built, I could compile a data structure with all image information, and load that in a predefined region in memory. At runtime image A or whoever image wants to discover about the others would read this structure from a predefined location.

Do you have any cleaner, simpler solutions?

Many thanks, Bahadir

Reply to
Bahadir Balban
Loading thread data ...

I had to deal with similar problem once. I quickly decided on something like your #3 solution because it was straightforward and not too hard to implement.

You're right about tedious hand manipulations of linker control files based on previous link outputs: after a few rounds of doing that and maybe even after dealing with a few hair pulling mistakes, you'll eventually end up using your automatic/programmatic solution and never regret your final choice.

JJS

Reply to
johnspeth

On 14/11/2006 the venerable Bahadir Balban etched in runes:

Yes, use a boot loader.

--
John B
Reply to
John B

If you're using the GNU linker, you could possibly use a combination of A) and B).

First, link the images separately, but so that the output is still relocatable.

Second, locate the images to an output image with a special linker script. The script can recognize the modules (A or B) in addition to the sections of the input files and locate them according to instructions in the script.

HTH

--

Tauno Voipio
tauno voipio (at) iki fi
Reply to
Tauno Voipio

Or use an MMU. Assum you have 'n' bytes of memory. Allocate 'n' bytes in the page table for image A, and 'n' bytes in the page table for image B.

You now know that Image A starts at address 0 and image B starts at address B. Allocate physical memory as needed for the two images.

A simpler alternative is to let image B call a subroutine in image A. The subroutine needs to be at a fixed address which is never changed. The parameters of the subroutine should be the info A needs to know about B, and maybe also include the address of a subroutine in B, so that A can return the favour.

--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB
Reply to
Ulf Samuelsson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.