Copyright 1995 D. Hanson, K. Li & J.P. Singh Computer Science 217: Linking and Loading Page 226 November 24, 1997 Linking and Loading • Generating an a.out is a two-step process • Why two steps? • Linkers combine multiple object files into one executable file e.g., a.out , and perform external symbol resolution and relocation • Other linker capabilities: segments, e.g., text & data, library searching... assembler as objectcodeassemblylanguagelinker lda.out objectcodeCopyright 1995 D. Hanson, K. Li & J.P. Singh Computer Science 217: Example Page 227 November 24, 1997 Example • main.c : static int a;extern int b;int c[10];main() {f(a, b);g(a, b);} • Compiling and linking % lcc -v -c main.c /usr/princeton/lib/gnu/gcc-cpp ... main.c |/usr/princeton/lib/rcc -v -o /tmp/lcc24417.s /bin/as -o main.o /tmp/lcc24417.srm /tmp/lcc24417.s% nm main.o 00000050 b _a U _b00000028 C _c U _f U _g 00000000 T _main% • f.c : int b;f(int a, int b) {return a + b;}g(int a, int b) {return a - b;} % lcc -c f.c% nm f.o00000004 C _b00000000 T _f0000000c T _g% lcc -v main.o f.o /bin/ld -o a.out -dc -dp-e start -X /usr/lib/crt0.omain.o f.o -lm -lcCopyright 1995 D. Hanson, K. Li & J.P. Singh Computer Science 217: Relocation Page 228 November 24, 1997 Relocation • Relocation : assembler assumes each module begins at address 0 • When main.o and f.o are linked, addresses must be relocated , why? • Modules are concatenated in the order in which they are given to ld ; but the compiler might rearrange data or functions arbitrarily % lcc main.o f.o % nm a.out00004000 d __DYNAMIC 000040c8 b _a00004098 B _b000040a0 B _c 00004098 D _edata000040d0 B _end00004090 D _environ000024c4 T _etext 000022e0 T _f000022ec T _g00002290 T _main ... • Object code contains information about relocation sites % lcc f.o main.o % nm a.out00004000 d __DYNAMIC 000040c8 b _a00004098 B _b000040a0 B _c 00004098 D _edata000040d0 B _end00004090 D _environ000024c4 T _etext 00002290 T _f0000229c T _g000022a8 T _main ...Copyright 1995 D. Hanson, K. Li & J.P. Singh Computer Science 217: Symbol Resolution Page 229 November 24, 1997 Symbol Resolution • Linking must resolve all symbols ; undefined symbols are errors % lcc main.old: Undefined symbol _b _f _g • Linking must define each symbol once ; multiple definitions are errors % cp f.o g.o% lcc main.o f.o g.old: g.o: _f: multiply definedg.o: _g: multiply defined • Linkers do not type check across modules; types of undefined and defined symbols must agree or else ... • Linkers combine all modules specified, even if some are not referenced • Undefined symbols drive library searching lcc -o cw main.o /u/cs217/lib/lib217.a -lc main.o references but does not define parse , Table_ *, and C library functionsonly those modules that define one of these symbols are linked from lib217.a and from the C library (specified by -lc )Copyright 1995 D. Hanson, K. Li & J.P. Singh Computer Science 217: Linking and Loading, cont’d Page 230 November 24, 1997 Linking and Loading, cont’d • “Linking loaders” consume object files, produce an executable file • “Link editors” consume object files, produce executable or object file • Link editors (like ld ) can build an object file iteratively % ld -o ab.o -r a.o b.o% ld -o a.out ab.o c.o -r causes ld to keep relocation information and generate an object fileexecutable files normally have no relocation information • Executable files do contain a symbol table , which is useful for debugging but takes space; it can removed by “stripping” the executable % lcc -o cw main.o lib217.a% ls -l cw24576 cw% nm cw000028a0 T _Table_install...00002d88 T _parse...% strip cw % ls -l cw16384 cw% nm cwnm: cw: no name
View Full Document
Unlocking...