OSDev.org

Ok. Yes, I have scanned throu the famous Linkers-Document. I have understood the basics. Now, I want to know how it *works*

Say, you bind a program dynamically against a library (say library.o) The executeable sports a library (ld.o?), which is responsible for resolving symbols at runtime:

Here I have questions:
1. A shared library is shared memory with some additional properties (name, size, table of relative adresses to functions)

2. The executeable of our program sports a table of calls to the functions in the shared library. Those function calls have to be resolved - either upon fetching the library or upon call.

3. the executeable has a table of libraries to be loaded.

4. ld.o is responsible for the resolving of the symbols in the call table for this library - thus resolving "external calls to module XXX" at runtime.

5. scheme of how it might work:

Program starts up. crt0 performs some checks. Eventually it calls ld.o - load_library("name") for each library in the table of required libraries. ld.o fetches the libraries: is a library present, map it in and perform the binding agains the local table of calls. else have the library manager load the library, create a shared memory mapping and hand over a name for the library - then map it in and perform the binding (filling in the call table with the corresp. addresses)

then the program starts to work and can use all the libraries as if linked statically.

That's the scheme as I understand it. Are there any flaws in it? is there more to add?

Thanks for your input!

That's one way to do it, and the way it's being done on Unix-ish systems, yes.

];->

What does the 'yes' refer to? Flaws? Things to add? *ssffgg*

Out of time I daresay, else you wouldna be that greedy with words. *rofl*

I've only had limited experience with Dynamic Linking (having written ld.so functionality into my bootloader for my Kernel) but I think I have a decent understanding of the ELF docs.

The Kernel maps in the program using the Program Headers as per usual with static apps, a dynamically linked app will instruct the Kernel to load the complete file (ie. ELF Header, Program Header and all) into memory. The Program Header will also contain an "Interpreter Path" entry which is the path to ld.so. The Kernel then maps that in memory anywhere it likes by using its Program Headers, the Kernel then pushes a few params on the userspace stack (can't remember what they are right now but one of them is whereever the Kernel put ld.so as well as a pointer to the program image) then the kernel starts ld.so's entry point.

ld.so then relocates itself then the program (if neccessary) then remaps the program's GOT to point to its symbol resolver function, it then links the libraries as the program calls functions. I think it loads all libraries at startup and calls their .init functions but doesn't resolve anything unless Lazy Binding is off, that's all to do with ld.so's internal workings though.

beyond infinity wrote: What does the 'yes' refer to? Flaws? Things to add? *ssffgg*

"Yes, that's the way Unixes do it."

Out of time I daresay, else you wouldna be that greedy with words. *rofl*

As always. :-\