Dynamic Loading

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
(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.

Arik



Re: Dynamic Loading
 
Quoted text here. Click to load it

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,

Ico

--
:wq
^X^Cy^K^X^C^C^C^C

Re: Dynamic Loading
Ico,

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 in advance,
Arik

Quoted text here. Click to load it



Re: Dynamic Loading
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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 ?

Quoted text here. Click to load it

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)

Quoted text here. Click to load it

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.

_Ico


--
:wq
^X^Cy^K^X^C^C^C^C

Re: Dynamic Loading
Quoted text here. Click to load it

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.

Re: Dynamic Loading
On Wed, 21 Dec 2005 13:30:44 +0200, "ArikG"

Quoted text here. Click to load it


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


Re: Dynamic Loading



Quoted text here. Click to load it

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.


Site Timeline