1. Home
  2. Embedded Programming
  3. Embedded dlls or linkable modules question

Embedded dlls or linkable modules question

Hi,

I am beginning an embedded project based on the gcc C++ toolset and would like to be able to have software modules that are loadable seperately from my main program. Kind of like embedded dynamic link libraries in that I want to be able to download them to the target file system and have the main program find those modules presaent and be able to run the code contained in them. The reason is that the hardware and software is very modular and I want to be able to have one main SW build that I can very easily change in the field so support new functionality without recompiling.

I know that there are lots of embedded OSs that support "dll"s in one form or another but I want to use an unhosted compiler (ie write to the bare metal) if possible, or alternatively to use something like RTEMS which does not support dlls. My vague ideas include something like embedding the gnu linker ld but I wondered if anyone here has ever done anything with a similar intent before I started down this path ?

Thanks,

Boo

Reply to
Boo
Loading thread data ...

The ELF binaries produced by the GNU toolkit (gcc, as, ld and utilities) are suitable for dynamic loading.

You need a dynamic loader in your system. For an example, have a look at the Linux ld.so loader sources.

Please understand that the dynamic loader is not a simple thing. It is probably too large for an embedded system.

--

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

The first problem is relocation of absolute addresses. If your system supports position independend code (-fPIC) you are done.

Then put a jump table at the beginning of your binary, maybe plus a signature, and use function pointers in order to access the additional modules from the main block.

Mit freundlichen Grüßen

Frank-Christian Krügel

Reply to
Frank-Christian Kruegel

if

support

I

Or you could use the resident library concept from the old AmigaDOS (which is based on an even older OS). Entry points to the library functions are a jump table at the beginning of the library. The OS maintains a directory of base addresses for libraries by name. Loading a library entails only relocating absolute addresses which is quite simple. If the libraries are reentrant, one copy of a given library suffices for multiple programs/processes/threads.

Reply to
Everett M. Greene

...

I think that what you want used to be called "relocatable binary overlays". There are two issues:

1) relocation 2) linking

Brute force and ignorance relocation can be done by compiling twice at different addresses and producing a relocation list, which is then attached to the overlay's binary. The number and types of relocation required will depend on the compiler.

Linking is just a matter of patching jump addresses in a table or linked list.

We've implemented these schemes a number of times.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Reply to
Stephen Pelc

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.