OSDev.org

Hi guys,
I've a question, Is dynamic linking the job of kernel, or the linker puts some piece of code that runs before the main() function to do the relocation and load other shared libraries as well?

So is it a kernel's job or the linker's one ?

Thanks

As is with all design decisions, that depends upon your design, justificaion and the enviroment you have chosen for your system.

If you were to implement the relocation in Kernel Land, you would have the advantage of being able to manage the relocation over numerous addresse spaces (if this is a requirement), and therefore be able to minimize having to increase RAM usage by storing a seperately relocated copied of each DLL for each process. You could simply share DLL's located at the same position and only Make a full copy when it is neccesary because the address is unavailable. In this method you would be locked into the executable format's supported by the kernel (or it's loaded modules), but in a Hobby System, this should be no problem.

In this case of a User land libraries (An option you didn't consider), you have the same basic setup as with kernel land (Only support what is already known by the system) but lose the natural advantage of process synchronised relocation. This could of course be eleviated by IPC, or simply requesting the area directly from the kernel and then editing the single copy for an area you know is available on all dependent address spaces.

By including the Dynamic Linker in the Executable, the least common method in current major Operating Systems, you have the advantage of not depending upon the Operating System to know the format, as long as it has the neccesary Primitives to support any work the relocation requires. Once again, IPC or a Memory Check by the Kernel would be needed if you were to communicate the location between processes for a single in-memory copy of the DLL.

Personally i would use Kernel Loadable Dynamic Linker's for each supported format because of the Monolithic style of my code and as an attempt to stream line the structure as much as possible and prevent excessive use of different formats. It would also mean not having to ship the linker with every executable, greatly increasing Memory and Secondary Storage usage.

Of course, it's your system, you decide.

I am currently finishing up (hopefully!) my relocation code, which resides in my kernel. A few reasons I chose this method: OS supports one known format, kernel can relocate and link files together using said format. This means, my relocation code need only be written once. For my drivers, which all reside in the same memory space and can communicate with each other, I can link them and the function calling is just as if all the drivers were compiled as one (so it makes it a bit faster). Also, since all my program files and drivers use the same format, it makes debugging and writing code much simpler for everyone . I have a method to find a symbol address by it's name, so when my kernel loads drivers, it relocates them, and links them to itself, so any kernel functions the drivers use are automagically linked at load time. This means, if I re-write my kernel, as long as the same function names are available, my drivers will still work, so it makes things very easy. If you have a relocation stub in each program, you are increasing its size, and it may or my not play nicely with external libraries (which is responsible for linking to which, the library or the application?). I use a standard format (coff files right now, may change if i need it to, but so far it's good enough), which is easily supported by nasm, ld, and most other tools. I have a function to find a symbol address by name (since i have to link files dynamically), which plays nicely, since each of my drivers is required to have 2 things, a DriverInfo struct filled out, and an Inititalization function so when my kernel loads the driver it knows some info about it and initializes it. The good thing is, both of these can be located anywhere in the file without worry from the programmers perspective.