Dynamic Linking of librairies without and OS

Hi,
I'm trying to create a simple plugin architecture on a microcontroller
without an OS. My main issue is how to dynamically link a shared objects
library (.so). On a Linux system, we can use dlopen and dlsym to achieve
that. I was wondering if anyone has tried to achieve this or has any
information if this is even achievable without an OS.

Thanks,
Amer


---------------------------------------
Posted through http://www.EmbeddedRelated.com

On Mon, 13 Jul 2015 22:12:51 -0500, araad wrote:

> Hi,
> I'm trying to create a simple plugin architecture on a microcontroller
> without an OS. My main issue is how to dynamically link a shared objects
> library (.so). On a Linux system, we can use dlopen and dlsym to achieve
> that. I was wondering if anyone has tried to achieve this or has any
> information if this is even achievable without an OS.

I think that by the time you've achieved it you will have developed a 
good portion of an OS.  Why reinvent the wheel?


-- 
www.wescottdesign.com

On Mon, 13 Jul 2015 22:12:51 -0500, "araad" <107116@EmbeddedRelated>
wrote:

>Hi,
>I'm trying to create a simple plugin architecture on a microcontroller
>without an OS. My main issue is how to dynamically link a shared objects
>library (.so). On a Linux system, we can use dlopen and dlsym to achieve
>that. I was wondering if anyone has tried to achieve this or has any
>information if this is even achievable without an OS.

If you really intend to use some existing .so files produced for the
Linux system, then you need some kind of linking loader. You have to
do the fixups, handle external references to (C) libraries, possibly
rebase the library code itself.

More realistic for small embedded systems would be to build self
contained files (no external references) linked to a fixed load
address (and use different load addresses for each library). A jump
table in the beginning of each library helps managing the project. To
call a specific function in a library, you only need to know the
library base load address and the ordinal number of the function
pointer in the jump table.

In the days when programming a single EPROM took more than 5 minutes,
I used this principle with library code linked to an absolute image
with jump tables in the beginning and then only once burned into an
EPROM. Making changes to the application was easier, when  you didn't
have to reburn the library EPROMS. I think you could get some ideas
from this, if you can make the library a self contained (no
relocations) file with absolute addresses.  

Clifford Heath wrote:
> On 14/07/15 13:12, araad wrote:
>> I'm trying to create a simple plugin architecture on a microcontroller
>> without an OS. My main issue is how to dynamically link a shared objects
>> library (.so). On a Linux system, we can use dlopen and dlsym to achieve
>> that. I was wondering if anyone has tried to achieve this or has any
>> information if this is even achievable without an OS.
[...]
> In short, you can do this too. If you don't need to load shared
> libraries, then you just need to find the sizes and alignment
> requirements of the code and data sections in the loadable module,
> allocate memory for each section, read in the code or data, and then
> read through the relocations section of the executable file, applying
> fixups to adjust for the actual addresses of the memory you allocated.

Ideally, if the library was built as an actual shared library, you do
not even have to process relocations. Processing relocations definitely
is not fun on some platforms.

First thing for OP to check would be whether their compiler/linker can
actually build real position-independant shared libraries. If they do,
implementing an ELF loader costs about a week time.

If that fails, plan B would be to make plugins self-contained and linked
to a fixed address, with a jump table in a custom format. This way, the
normal linker (maybe even the normal loader, so you don't need your own
ELF parser) can be used to generate the plugin.


  Stefan