Download Multics: Dynamic Linking - Understanding the Concepts and Implementation and more Slides Computer Numerical Control in PDF only on Docsity!
Multics: Dynamic Linking
Arvind Krishnamurthy
Spring 2004
Multics
n Today: look at Mutics VM
n CTSS: probably the first time-sharing system (1959-1965)
n “Compatible Interactive Time Sharing System” n Introduced: n working online n storing information online n No protection, off-the-shelf hardware n 4 consoles running at 110 baud attached to an IBM machine n Two tape drives/user, swapped programs and data n Introduced interactive debugging, editors, command-line processors n Simple, few key ideas, throw out irrelevant, highly successful
Multics (MIT/Bell/GE)
n Multics: “second system effect”
n Huge, complicated, tough to debug, terrible performance
n Designed around 1965
n New hardware, new OS, new programming language n Multiple processes, separate address spaces, segmentation with paging n Take an interesting idea to the extreme (good research direction!) n Extreme sharing n Support sharing & dynamic linking
n Unix: third system
n Understand the limits from the second system, step back, choose with taste, pick some key ideas
Key Ideas in Multics VM
n Combine virtual memory & file systems n Two ways to refer to data: (segment number, offset) and (file name, offset); segment is stored on disk or memory n Kind of like “mmap” for all data n Fine-grain sharing n Multics took sharing to the extreme n Sharing at the level of segments n Process = many segments (data or code) n Individual library packages are shared; different subsets of processes share different libraries n Dynamic linking n Segments can be “made known” at runtime n Share information and upgrade incrementally n Autonomy (independent address space per. process) n Two different libraries might be at different addresses on different processes n Need that if we have to support fine-grain sharing
Combined Result
000: move 100, r 004: store 11, (r1) 008: move 104, r 00C: store 12, (r2) 010: jsr 018 014: ret 018: move 100, r 01C: store 1, (r1) 020: move 104, r 024: store 2, (r2) 028: ret
100: (space for y) 104: (space for z)
Dynamic Linking: Step 1
n Resolving external references at runtime
n Use a level of indirection:
n Initially symbolic references, later become memory references
Indirect Call (^) “libc:fprintf” Indirect Call
n “Link trap” occurs on first reference n Linker appends the segment to segment table n Finds the symbol in symbol table for “fprintf” n Overwrite the pointer to symbolic address n Return back and retry the instruction
libc:
0xabcd:fprintf
0xabcd
Rewrite Symbolic references
extern int y; /* “foo” */ int z;
int main() { ... z = y + 1; ... }
004: move 0x100, r 008: load (r2), r 00C: load (r3), r 010: add r4, 1, r 014: store r5, ...
100: Address: 0x
200: “foo:y”
Has “symbolic ref” bit set to cause a link trap
n Add a level of indirection:
n To prevent modifying code n To share pointer across many references
Rewrite Symbolic references
004: move 0x100, r 008: load (r2), r 00C: load (r3), r 010: add r4, 1, r 014: store r5, ...
100: Address: 0x
200: “foo:y”
004: move 0x100, r 008: load (r2), r 00C: load (r3), r 010: add r4, 1, r 014: store r5, ...
100: Address: 1004
1004: location of y 1008: ...
foo:
Linkage Section Example
Linkage section for “prog” Has 2 entries:
000: Address 100 004: Address 200
100: “foo::y” 200: “bar::z”
extern int foo::y; extern int bar::z;
int progtest() { ... z = y; ... } [prog.c]
004: load 0(LP), r 008: load (r2), r 00C: load 4(LP), r 010: store r3, (r4)
Process so far…
n When process refers to the “prog” segment
n “link trap” happens n Make code segment “prog” known n Instantiate linkage section for “prog” in the linkage segment n Use symbol table, cross-reference list from the object file
n When the code segment refers to the data “foo::y”
n “link trap” happens n foo’s segment is loaded and foo’s linkage section is instantiated n Modify address in linkage section for “prog” to point to “foo::y”
n Only problem left: how do you get the linkage pointer
register point to the right place?
Step 3: Procedure call
n When PC is in segment, LP points to the segment’s linkage
section
n At every procedure call, change LP
n How to do this?
Procedure Call
n When S1 calls prog::progtest
n Change LP to point to prog’s linkage section n Then, jump to progtest n Now progtest’s references will go through prog’s linkage section (for the current process only)
call progtest
S
progtest:
prog (^) S1’s Linkage section
prog’s Linkage section
Set LP; Jump progtest;
Postscript
n Why so complicated?
n Fine-grained sharing n Dynamic linking n Independent address spaces
n For the next 20 years, no one attempted dynamic linking
and sharing at the same time
n Until MIT takes revenge:
n MIT X-windows: megabytes of X toolkits n Need shared libraries
n Similar mechanisms are now standard in all major
operating systems
