Hi There !
Hope you all are fine. I am studying dynamic linking in operating system memory management. I am little bit confused about the scope of dynamic linking. It is said it links the library at the run time when the .exe is loaded in the memory for execution. It makes sense when the new program is going to be installed in the system therefore at that time the code will search for libraries and then embed the code of libraries into the installed image. Does it also imply on the already installed program. For example in windows if we click some program it will load its code in the memory, will it also do dynamic linking at that time but how ??
BR
Green
Knowledge is Power but information is more Powerful than Knowledge
The concept of dynamic linking ?
-
ApproximateIdentity
- Posts: 16
- Joined: Sun Dec 08, 2013 4:14 pm
Re: The concept of dynamic linking ?
The details are more complicated (and vary according to OS), but I can probably clear up the idea...
Say you compile a program which calls printf from the standard C library. If you compile the program with dynamic linking, it will not actually embed the code for printf in the binary, but instead just put in a marker (say "call $printf$lc" or something conceptually similar) and leave it at that. This means that the binary itself is not "complete" in the sense that it calls functions which it doesn't actually have code for.
Later when the binary is loaded (i.e. because you executed it), it doesn't just start executing immediately, but instead loads the missing pieces first. For example, a simple implementation might just search some specific folders for the library (libc in this case) and then extract the code for printf. Then it might load that code somewhere into the binary image and then replace $printf$lc with the address where the function was loaded. This will usually be invisible to the user. I.e. whether binary is static (has no dynamic linking) or it is dynamic doesn't matter to the user: in most cases you'll just call it with something like ./prog.
That's a simplification, but that's the basic idea. There are many optimizations to this. For example, much of the code that you load might actually be readonly and so different processes can share that code. I.e. the first time a process loads printf, the loader actually loads the code. The second time a process loads printf, the loader simply uses the same code that was already loaded, though probably the process thinks it's loaded at a different address. In fact, that is one reason why you'll need help from the OS. Another thing is that you will presumably not be loading things on a function level, but something more course (i.e. you won't only load in printf, but possibly instead all functions in the c library).
As with all OS concepts the details are confusing and usually different than what I said, but that's the main idea. Hopefully this makes some sense.
Say you compile a program which calls printf from the standard C library. If you compile the program with dynamic linking, it will not actually embed the code for printf in the binary, but instead just put in a marker (say "call $printf$lc" or something conceptually similar) and leave it at that. This means that the binary itself is not "complete" in the sense that it calls functions which it doesn't actually have code for.
Later when the binary is loaded (i.e. because you executed it), it doesn't just start executing immediately, but instead loads the missing pieces first. For example, a simple implementation might just search some specific folders for the library (libc in this case) and then extract the code for printf. Then it might load that code somewhere into the binary image and then replace $printf$lc with the address where the function was loaded. This will usually be invisible to the user. I.e. whether binary is static (has no dynamic linking) or it is dynamic doesn't matter to the user: in most cases you'll just call it with something like ./prog.
That's a simplification, but that's the basic idea. There are many optimizations to this. For example, much of the code that you load might actually be readonly and so different processes can share that code. I.e. the first time a process loads printf, the loader actually loads the code. The second time a process loads printf, the loader simply uses the same code that was already loaded, though probably the process thinks it's loaded at a different address. In fact, that is one reason why you'll need help from the OS. Another thing is that you will presumably not be loading things on a function level, but something more course (i.e. you won't only load in printf, but possibly instead all functions in the c library).
As with all OS concepts the details are confusing and usually different than what I said, but that's the main idea. Hopefully this makes some sense.
Re: The concept of dynamic linking ?
Specifically, for windows DLLs, there is a table of external functions in your EXE (or DLL), which contains the name and/or index of the needed functions. After the EXE is loaded into memory, windows updates this table and records the address of each function in the table. Then the program uses this table to call those functions.
This is a simplified description, but you should get the idea.
This is a simplified description, but you should get the idea.
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Re: The concept of dynamic linking ?
Hi, green1.
I don't understand a bit. Do you want to know why does the OS need a dynamic memory allocator or how does it look at user's glance?
I don't understand a bit. Do you want to know why does the OS need a dynamic memory allocator or how does it look at user's glance?
Re: The concept of dynamic linking ?
green1 wrote:Hi There !
For example in windows if we click some program it will load its code in the memory, will it also do dynamic linking at that time but how ??
Do not quite familiar with windows, buf in linux, it indeed.
HOW:
it's a long story. i can not tell you all the details here. checkout elf Spec, or
i have written a blog post.
i remembered i once saw some code snippets in wiki,but i can not find it now.
-
carbonBased
- Member
- Posts: 382
- Joined: Sat Nov 20, 2004 12:00 am
- Location: Wellesley, Ontario, Canada
- Contact:
Re: The concept of dynamic linking ?
fwiw, I have a fairly trivial example of run-time linking in my OS (ndk).
I basically ported the existing rdoff2 linker to run in my kernel, such that I could load object files, and link them to symbols in the kernel.
The OS is available at www.neuraldk.org
It's not a stellar example, but it's simple. Hopefully easy to follow.
Effectively, the OS parses the obj headers, and looks for external symbols, and compares those symbols against a table which the OS exports. If it finds a match, the address in the loaded object file is patched up to reference the OS symbols location.
--Jeff
I basically ported the existing rdoff2 linker to run in my kernel, such that I could load object files, and link them to symbols in the kernel.
The OS is available at www.neuraldk.org
It's not a stellar example, but it's simple. Hopefully easy to follow.
Effectively, the OS parses the obj headers, and looks for external symbols, and compares those symbols against a table which the OS exports. If it finds a match, the address in the loaded object file is patched up to reference the OS symbols location.
--Jeff