1 / 8

Linking and Loading

Linking and Loading. Linker collects procedures and links them together object modules into one executable program. Why isn't everything written as just one big program, saving the necessity of linking?

rashad
Télécharger la présentation

Linking and Loading

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Linking and Loading • Linker collects procedures and links them together object modules into one executable program. • Why isn't everything written as just one big program, saving the necessity of linking? • Efficiency: if just one function is changed in a 100K line program, why recompile the whole program? Just recompile the one function and relink. • Multiple-language programs • Other reasons?

  2. Relocation • Before widespread support for virtual memory, code had to be relocatable (could not contain fixed memory addresses) • With VM, when a page is swapped out, bringing it back in makes the references change (update PT) • With shared libraries, each library decides on its own (fixed) addresses  collision of addresses • Relocation problem same as before virtual memory • What is the problem? No fixed addresses (calls, vars, ifs) • What is the solution? Shared libraries!

  3. Object Modules: linking and loading • Structure of an object module • Entry points • External symbols • Binding time and dynamic relocation: possible binding times • Virtual addresses • Relocation register • Use addresses relative to program counter

  4. Dynamic linking • Unix systems: Code is typically compiled as a dynamic shared object (DSO): • Dynamic vs. static linking $ gcc -static hello.c -o hello-static $ gcc hello.c -o hello-dynamic $ ls -l hello 80 hello.c 13724 hello-dynamic 383 hello.s1688756 hello-static • if you are the sys admin, which do you prefer?

  5. Advantages of dynamic linking • The executable is smaller (it not include the library information explicitly), • When the library is changed, the code that references it does not usually need to be recompiled. • The executable accesses the .DLL at run time; therefore, multiple codes can access the same .DLL at the same time (saves memory)

  6. Shortcomings of dynamic linking • Performance hit ~10% • Need to load shared objects (once) • Need to resolve addresses (once or every time) • What if the necessary dynamic library is missing? • Could have the library, but wrong version

  7. Unix Dynamic Objects (.so) • Host library • Target library • Compiler Options (cont) • -nostartfiles skip linking of standard start files, like /usr/lib/crt[0,1].o, /usr/lib/crti.o, etc. • -static link only to static (.a=archive) libraries • -shared if possible, prefer shared libraries over static • Linker Options (gcc gives unknown options to linker) • -l lib (default naming convention liblib.a) • -L lib path (in addition to default /usr/lib and /lib) • -s strip final executable code of symbol and relocation tables

  8. DLL: dynamic link libraries • Static Windows libraries are .LIB • Implicit linking • Statically linked to import library • Checks which DLLs in memory & loads missing ones • Have to map DLLs into program address space • Explicit linking • prog makes explicit runtime to bind to DLL, then • makes a call per procedure to determine address • then calls procedure. • What are the pros/cons of the two approaches?

More Related