Dynamic Loading

(I am using Algorithmic sde-gcc for MIPS core)

I would like to create some kind of DLL in my Embedded system. i.e. I want to save memory space by dynamic load module or library only if it required.

Please advice how can I handle this.


Reply to
Loading thread data ...

One important choice has to be made: 1) will you only load one, and only one, different dynamic module at any time, or 2) do you want multiple dynamic modules to be loaded at the same time ?

1) Static addresses

In the first case the solution could by quite simple : you probably know where you will load the code, so just compile the source and tell your linker the address where the binary will be located. Publish some `well known addresses' for functions and/or global data so other code knows how to acccess the module. Using software interrupts (SWI) for entry to the code is commonly used as well.

2) Dynamic addresses

The second case is more complicated, because you can't always tell on what address the code will be loaded.

You would - at least - need to do the folling :

- Enable the PIC (position independent code) option on your compiler when you compile your dynamic modules; this will make sure that the generated code will be relocateble to any address, since you don't know in advance at which address your code will be loaded

- You will have to do postpone and do some of the work of the linker yourself when you actually load the module into memory; This work consists mostly of filling in the addresses of functions and global/static data. Go find yourself some info on GOT (global offset tables) and linkers.

- Provide a mechanism for other code to 'find' the newly loaded module; this might require fiddling with global tables with symbol information and function pointers.

For more details you would have to provide more information on your embedded system; e.g. are you running an OS, what programming language(s) do you use, etc.

Good luck,


Reply to


Thank you for your response,

I am using threadX OS, and writing my code in "C".

My questions are:

  1. How should I pack my dynamic module, should it be different EXE ?
  2. How can I get services from my main application to my Dynamic Code ?

Thanks >

Reply to

Hello Arik,

Please don't post your messages on top of the responses, it's easier to follow a discussion if you write your text below the previous messages.

Well, I'm not familiar with threadX, so I'm afraid I can't tell you exactly how to do this. Have you considered contacting your OS vendor ?

This also depends on your environment and OS. As I said before, you should implement some of the linker functionality yourself, so you would probably have to invent your own 'binary format' as well. In your dynamic modules, you would need at least the following pieces :

- the actual code and data for the module, this would be the .text and .data sections your compiler spewed out.

- Information about the symbols containted in these sections. You should find out the names addresses of the public symbols in the .text, .data and .bss sections. Your compiler (or some other tool that came with it) is probably able to export these.

- Information about all addresses in your machine code which need to be 'filled in' by the linker. Your loader code should add (or substract) some offset to all of those addresses, depending of the actual address where the code is loaded. You would have to wrap all this information in some kind of binary format, and write the dynamic loader which takes all these pieces, loads the code in the memory, allocates and cleanes memory for the .bss section, relocates the dynamic addresses and stores the symbol information.

Ofcourse, if the binary format of your compiler is well documented, you could maybe use the '.o' or '.obj' files without change, since those usually hold all of the above information. (and a lot more, like debugging info, which you probably want to gemove from the files first)

The 'loader' you will have to write could keep a table of all the symbols it found in the dynamic modules, and you could provide a simple function which returns the address for a given symbol name.

What you are trying to do here is not a simple task; it requires a good understanding of the workings of your compiler, linker and CPU and probably requires a lot of debugging at assembly-level.


Reply to

You could look at how the OS used by the Commodore-Amiga computer did this. That method was based on an earlier OS whose name I've forgotten. 25+ year old technology/ technique.

Unless you have different libraries that have disjoint usage patterns, dynamic libraries are not going to save any memory space. At a minimum, you'll need a loader to bring the libraries into memory unless you get extremely lucky and can create libraries that need no code relocation, a function of the processor's archi- tecture.

Reply to
Everett M. Greene

AFAICR gcc supports overlays. This will only work if you have more ROM than ram. Your application also need to be able to be partition into portions that can execute fairly independantly. A portion of RAM is used for the overlayed code. All the code in the various overlays are statically linked to the same overlay area. Only one overlay can be executing at a specific time.

Regards Anton Erasmus

Reply to
Anton Erasmus

This would all assume your program is stored in non-executible media. Or, you OS executes out of RAM not ROM. Otherwise there are no savings.

Reply to
Neil Kurzman

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.