Dynamic Linking of librairies without and OS

Dynamic loading is often achieved (as in Linux) with user-mode code that runs before main() - it's not typically a kernel function any more.

The linker builds an import table which is saved to the executable file, listing the names and versions of the relocatable modules needed.

When the program starts, the dynamic loader (which is often in a shared library - which has specialised load code) searches for the shared library files containing the required code. For each such file, it allocates memory segments and reads or maps the code and initialised data into memory, relocating it if necessary (to whatever virtual address was allocated), and depending on the architecture, may build a jump table for the exported symbols. In the case of shared libraries, it's commonly the case that there is a single virtual address range reserved by the operating system, and all programs that share the same code will see it at the same virtual address.

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.

If you have no idea of the content of an relocatable image file, I'd suggest you start poking around one with binutils. You have a steep learning curve ahead of you, but it can be surmounted.

Clifford Heath.

Reply to
Clifford Heath
Loading thread data ...

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

formatting link

Reply to
araad

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
Reply to
Tim Wescott

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.

Reply to
upsidedown

[...]

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

Reply to
Stefan Reuther

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.