DOCSLIB.ORG

Symbol Table Relocation Table Object File Format Where Are We Now

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Symbol Table Relocation Table Object File Format Where Are We Now inst.eecs.berkeley.edu/~cs61c UCB CS61C : Machine Structures Symbol Table Lecture 19 – Running a Program II . List of “items” in this file that may be used by other files. (Compiling, Assembling, Linking, Loading) Hello to . What are they? Lecturer SOE 2008-03-05 Neil Sharma Labels: function calling Dan Garcia from the 3rd row! Data: anything in the .data section; variables which may be accessed across files Researchers at Princeton have developed a flexible electricity-producing sheet of rubber that can use body movements into electricity. Breathing generates 1 W, walking around the room generates 70 W. Shoes may be the best place, to power/recharge cell phones & iPods. www.nytimes.com/2010/03/02/science/02obribbon.html CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (3) Garcia, Spring 2010 © UCB Relocation Table Object File Format . List of “items” this file needs the address later. object file header: size and position of the other . What are they? pieces of the object file Any label jumped to: j or jal . text segment: the machine code internal . data segment: binary representation of the data in external (including lib files) the source file Any piece of data connected with an address . relocation information: identifies lines of code that such as the la instruction need to be “handled” . symbol table: list of this file’s labels and data that can be referenced . debugging information . A standard format is ELF (except MS) http://www.skyfree.org/linux/references/ELF_Format.pdf CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (4) Garcia, Spring 2010 © UCB CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (5) Garcia, Spring 2010 © UCB Where Are We Now? Linker (1/3) . Input: Object Code files, information tables (e.g., foo.o,libc.o for MIPS) . Output: Executable Code (e.g., a.out for MIPS) . Combines several object (.o) files into a single executable (“linking”) . Enable Separate Compilation of files Changes to one file do not require recompilation of whole program Windows NT source was > 40 M lines of code! Old name “Link Editor” from editing the “links” in jump and link instructions CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (6) Garcia, Spring 2010 © UCB CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (7) Garcia, Spring 2010 © UCB Linker (2/3) Linker (3/3) . Step 1: Take text segment from each .o file and .o file 1 put them together. text 1 . Step 2: Take data segment from each .o file, put a.out data 1 them together, and concatenate this onto end of Relocated text 1 info 1 text segments. Relocated text 2 Linker . Step 3: Resolve References .o file 2 Relocated data 1 Go through Relocation Table; handle each entry text 2 Relocated data 2 That is, fill in all absolute addresses data 2 info 2 CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (8) Garcia, Spring 2010 © UCB CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (9) Garcia, Spring 2010 © UCB Four Types of Addresses we’ll discuss Absolute Addresses in MIPS . PC-Relative Addressing (beq, bne) . Which instructions need relocation editing? never relocate J-format: jump, jump and link . Absolute Address (j, jal) j/jal" xxxxx" always relocate Loads and stores to variables in static area, relative . External Reference (usually jal) to global pointer always relocate lw/sw" $gp" $x" address" . Data Reference (often lui and ori) What about conditional branches? always relocate beq/bne" $rs" $rt" address" PC-relative addressing preserved even if code moves CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (10) Garcia, Spring 2010 © UCB CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (11) Garcia, Spring 2010 © UCB Resolving References (1/2) Resolving References (2/2) .! Linker assumes first word of first text segment is .! To resolve references: at address 0x00000000. ! search for reference (data or label) in all “user” ! (More later when we study “virtual memory”) symbol tables .! Linker knows: ! if not found, search library files (for example, for printf) ! length of each text and data segment ! once absolute address is determined, fill in the ! ordering of text and data segments machine code appropriately .! Linker calculates: .! Output of linker: executable file containing text ! absolute address of each label to be jumped to and data (plus header) (internal or external) and each piece of data being referenced CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (12) Garcia, Spring 2010 © UCB CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (13) Garcia, Spring 2010 © UCB en.wikipedia.org/wiki/Dynamic_linking Static vs Dynamically linked libraries Dynamically linked libraries .! What we’ve described is the traditional way: .! Space/time issues statically-linked approach ! + Storing a program requires less disk space ! The library is now part of the executable, so if the ! + Sending a program requires less time library updates, we don’t get the fix (have to ! + Executing two programs requires less memory (if recompile if we have source) they share a library) ! It includes the entire library even if not all of it will be ! – At runtime, there’s time overhead to do link used. .! Upgrades ! Executable is self-contained. ! + Replacing one file (libXYZ.so) upgrades every .! An alternative is dynamically linked libraries program that uses library “XYZ” (DLL), common on Windows & UNIX platforms ! – Having the executable isn’t enough anymore Overall, dynamic linking adds quite a bit of complexity to the compiler, linker, and operating system. However, it provides many benefits that often outweigh these. CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (14) Garcia, Spring 2010 © UCB CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (15) Garcia, Spring 2010 © UCB Dynamically linked libraries Administrivia…Midterm on Monday! .! The prevailing approach to dynamic linking uses .! Review Sat @ Time/location TBA machine code as the “lowest common .! Exam Mon @ 7-10pm in 1 Pimentel denominator” .! Covers labs, hw, proj, lec, book through today ! The linker does not use information about how the program or library was compiled (i.e., what compiler .! Bring… or language) ! NO cells, calculators, pagers, PDAs ! This can be described as “linking at the machine ! 2 writing implements (we’ll provide write-in exam code level” booklets) – pencils ok! ! Your green sheet (make sure to correct green sheet ! This isn’t the only way to do it... bugs) CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (16) Garcia, Spring 2010 © UCB CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (17) Garcia, Spring 2010 © UCB Upcoming Calendar Where Are We Now? Week # Mon Wed Thu Lab Fri #7 MIPS Inst Running Running Running Format III Program I Program Program II CS164 This week SDS I SDS II SDS SDS III #8 (TA) (TA) Midterm Next week 7-10pm 1 Pimentel #9 Students SDS IV SDS CPU I Explain (no class, Next next week Midterm! see webcast) Next3 week Spring Break! CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (18) Garcia, Spring 2010 © UCB CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (19) Garcia, Spring 2010 © UCB Loader (1/3) Loader (2/3) .! Input: Executable Code .! So what does a loader do? (e.g., a.out for MIPS) ! Reads executable file’s header to determine size of .! Output: (program is run) text and data segments ! Creates new address space for program large .! Executable files are stored on disk. enough to hold text and data segments, along with .! When one is run, loader’s job is to load it into a stack segment memory and start it running. ! Copies instructions and data from executable file .! In reality, loader is the operating system (OS) into the new address space ! loading is one of the OS tasks CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (20) Garcia, Spring 2010 © UCB CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (21) Garcia, Spring 2010 © UCB Loader (3/3) Things to Remember (1/3) .! Copies arguments passed to the program onto the stack .! Initializes machine registers ! Most registers cleared, but stack pointer assigned address of 1st free stack location .! Jumps to start-up routine that copies program’s arguments from stack to registers & sets the PC ! If main routine returns, start-up routine terminates program with the exit system call CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (22) Garcia, Spring 2010 © UCB CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (25) Garcia, Spring 2010 © UCB Things to Remember (2/3) Things to Remember 3/3 .! Compiler converts a single HLL file into a single assembly .! Stored Program concept is very powerful. It language file. means that instructions sometimes act just like .! Assembler removes pseudoinstructions, converts what it can data. Therefore we can use programs to to machine language, and creates a checklist for the linker (relocation table). A .s file becomes a .o file. manipulate other programs! ! Does 2 passes to resolve addresses, handling internal forward ! Compiler ⇒ Assembler ⇒ Linker (⇒ Loader) references .! Linker combines
Load more

Recommended publications
  • Linkers and Loaders Hui Chen Department of Computer & Information Science CUNY Brooklyn College
    CISC 3320 MW3 Linkers and Loaders Hui Chen Department of Computer & Information Science CUNY Brooklyn College CUNY | Brooklyn College: CISC 3320 9/11/2019 1 OS Acknowledgement • These slides are a revision of the slides by the authors of the textbook CUNY | Brooklyn College: CISC 3320 9/11/2019 2 OS Outline • Linkers and linking • Loaders and loading • Object and executable files CUNY | Brooklyn College: CISC 3320 9/11/2019 3 OS Authoring and Running a Program • A programmer writes a program in a programming language (the source code) • The program resides on disk as a binary executable file translated from the source code of the program • e.g., a.out or prog.exe • To run the program on a CPU • the program must be brought into memory, and • create a process for it • A multi-step process CUNY | Brooklyn College: CISC 3320 9/11/2019 4 OS CUNY | Brooklyn College: CISC 3320 9/11/2019 5 OS Compilation • Source files are compiled into object files • The object files are designed to be loaded into any physical memory location, a format known as an relocatable object file. CUNY | Brooklyn College: CISC 3320 9/11/2019 6 OS Relocatable Object File • Object code: formatted machine code, but typically non-executable • Many formats • The Executable and Linkable Format (ELF) • The Common Object File Format (COFF) CUNY | Brooklyn College: CISC 3320 9/11/2019 7 OS Examining an Object File • In Linux/UNIX, $ file main.o main.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped $ nm main.o • Also use objdump, readelf, elfutils, hexedit • You may need # apt-get install hexedit # apt-get install elfutils CUNY | Brooklyn College: CISC 3320 9/11/2019 8 OS Linking • During the linking phase, other object files or libraries may be included as well • Example: $ g++ -o main -lm main.o sumsine.o • A program consists of one or more object files.
    [Show full text]
  • Doin' the Eagle Rock
    VIRUS BULLETIN www.virusbtn.com MALWARE ANALYSIS 1 DOIN’ THE EAGLE ROCK this RNG in every virus for which he requires a source of random numbers. Peter Ferrie Microsoft, USA The virus then allocates two blocks of memory: one to hold the intermediate encoding of the virus body, and the other to hold the fully encoded virus body. The virus decompresses If a fi le contains no code, can it be executed? Can arithmetic a fi le header into the second block. The fi le header is operations be malicious? Here we have a fi le that contains compressed using a simple Run-Length Encoder algorithm. no code, and no data in any meaningful sense. All it The header is for a Windows Portable Executable fi le, and it contains is a block of relocation items, and all relocation seems as though the intention was to produce the smallest items do is cause a value to be added to locations in the possible header that can still be executed on Windows. There image. So, nothing but relocation items – and yet it also are overlapping sections, and ‘unnecessary’ fi elds have been contains W32/Lerock. removed. The virus then allocates a third block of memory, Lerock is written by the same virus author as W32/Fooper which will hold a copy of the unencoded virus body. (see VB, January 2010, p.4), and behaves in the same way at a The virus searches for zeroes within the unencoded memory high level, but at a lower level it differs in an interesting way.
    [Show full text]
  • 6 Boot Loader
    BootBoot LoaderLoader 66 6.1 INTRODUCTION The Boot Loader is a utility program supplied with the ADSP-21000 Family Development Software. The loader converts an ADSP-21xxx executable program, generated by the linker, into a format which can be used to boot a target hardware system and initialize its memory. The loader’s invocation command is LDR21K. The boot loader replaces the MEM21K memory initializer used with the ADSP-21020 processor. Any executable file to be processed with the LDR21K boot loader must not be processed by MEM21K. The -nomem switch of the C compiler should be used when compiling any C source files—this switch prevents the compiler from running MEM21K. The following naming conventions are used throughout this chapter: The loader refers to LDR21K contained in the software release. The boot loader refers to the executable file that performs the memory initialization on the target. The boot file refers to the output of the loader that contains the boot loader and the formatted system configurations. Booting refers to the process of loading the boot loader, initialization system memory, and starting the application on the target. Memory is referred to as being either data memory, program memory, or internal memory. Remember that the ADSP-21020 processor has separate external program and data memories, but does not have any internal memory. The ADSP-2106x SHARC has both internal and external memory. 6 – 1 66 BootBoot LoaderLoader To use the loader, you should be familiar with the hardware requirements of booting an ADSP-21000 target. See Chapter 11 of the ADSP-2106x SHARC User’s Manual or Chapter 9 of the ADSP-21020 User’s Manual for further information.
    [Show full text]
  • Common Object File Format (COFF)
    Application Report SPRAAO8–April 2009 Common Object File Format ..................................................................................................................................................... ABSTRACT The assembler and link step create object files in common object file format (COFF). COFF is an implementation of an object file format of the same name that was developed by AT&T for use on UNIX-based systems. This format encourages modular programming and provides powerful and flexible methods for managing code segments and target system memory. This appendix contains technical details about the Texas Instruments COFF object file structure. Much of this information pertains to the symbolic debugging information that is produced by the C compiler. The purpose of this application note is to provide supplementary information on the internal format of COFF object files. Topic .................................................................................................. Page 1 COFF File Structure .................................................................... 2 2 File Header Structure .................................................................. 4 3 Optional File Header Format ........................................................ 5 4 Section Header Structure............................................................. 5 5 Structuring Relocation Information ............................................... 7 6 Symbol Table Structure and Content........................................... 11 SPRAAO8–April 2009
    [Show full text]
  • Virtual Table Hijacking Protection Enhancement for CFG
    Liberation Guard: Virtual Table Hijacking Protection Enhancement for CFG Eyal Itkin [email protected] eyalitkin.wordpress.com Abstract—Control Flow Guard (CFG) is an advanced defense mechanism by Microsoft, that aims to mitigate exploiting tech- niques using control flow integrity checks. In this paper we1 present a proposed enhancement of CFG, that adds virtual table integrity checks which will mitigate most virtual table hijacking exploits. The proposed defense creates a strong differentiation between ordinary and virtual functions, thus significantly nar- rowing the exploit options available when controlling an indirect virtual call. This differentiation will impose strong restrictions over current virtual table hijacking exploits, thus significantly raising the protection CFG can offer to protected programs2. I. PRELIMINARIES Fig. 1. Example of address translation for an unaligned address (at the top) and an aligned address (at the bottom). A. Control Flow Guard Overview Control Flow Guard (CFG) is an advanced control flow integrity (CFI) defense mechanism introduced by Microsoft in In order to use this CFI knowledge, the compiler adds Windows 8.1 and Windows 10 [4]. CFG aims to significantly a validation check prior to each indirect call (only call restrict the allowed control flow in the cases of indirect calls, assembly opcode, and not jump opcodes). This function is and is supported in Visual Studio 2015. stored in ntdll.dll, and exported to the rest of the DLLs. This defense mechanism is based on the fact that during The function verifies the requested address against the stored compilation time the compiler ”learns” where ”legitimate” bitmap, while acting as a NOP in case the bit is ”1” and crashes functions start, and records these addresses in the compiled the program in case the bit is ”0”.
    [Show full text]
  • Tricore Architecture Manual for a Detailed Discussion of Instruction Set Encoding and Semantics
    User’s Manual, v2.3, Feb. 2007 TriCore 32-bit Unified Processor Core Embedded Applications Binary Interface (EABI) Microcontrollers Edition 2007-02 Published by Infineon Technologies AG 81726 München, Germany © Infineon Technologies AG 2007. All Rights Reserved. Legal Disclaimer The information given in this document shall in no event be regarded as a guarantee of conditions or characteristics (“Beschaffenheitsgarantie”). With respect to any examples or hints given herein, any typical values stated herein and/or any information regarding the application of the device, Infineon Technologies hereby disclaims any and all warranties and liabilities of any kind, including without limitation warranties of non- infringement of intellectual property rights of any third party. Information For further information on technology, delivery terms and conditions and prices please contact your nearest Infineon Technologies Office (www.infineon.com). Warnings Due to technical requirements components may contain dangerous substances. For information on the types in question please contact your nearest Infineon Technologies Office. Infineon Technologies Components may only be used in life-support devices or systems with the express written approval of Infineon Technologies, if a failure of such components can reasonably be expected to cause the failure of that life-support device or system, or to affect the safety or effectiveness of that device or system. Life support devices or systems are intended to be implanted in the human body, or to support and/or maintain and sustain and/or protect human life. If they fail, it is reasonable to assume that the health of the user or other persons may be endangered. User’s Manual, v2.3, Feb.
    [Show full text]
  • The UNIX Time- Sharing System
    1. Introduction There have been three versions of UNIX. The earliest version (circa 1969–70) ran on the Digital Equipment Cor- poration PDP-7 and -9 computers. The second version ran on the unprotected PDP-11/20 computer. This paper describes only the PDP-11/40 and /45 [l] system since it is The UNIX Time- more modern and many of the differences between it and older UNIX systems result from redesign of features found Sharing System to be deficient or lacking. Since PDP-11 UNIX became operational in February Dennis M. Ritchie and Ken Thompson 1971, about 40 installations have been put into service; they Bell Laboratories are generally smaller than the system described here. Most of them are engaged in applications such as the preparation and formatting of patent applications and other textual material, the collection and processing of trouble data from various switching machines within the Bell System, and recording and checking telephone service orders. Our own installation is used mainly for research in operating sys- tems, languages, computer networks, and other topics in computer science, and also for document preparation. UNIX is a general-purpose, multi-user, interactive Perhaps the most important achievement of UNIX is to operating system for the Digital Equipment Corpora- demonstrate that a powerful operating system for interac- tion PDP-11/40 and 11/45 computers. It offers a number tive use need not be expensive either in equipment or in of features seldom found even in larger operating sys- human effort: UNIX can run on hardware costing as little as tems, including: (1) a hierarchical file system incorpo- $40,000, and less than two man years were spent on the rating demountable volumes; (2) compatible file, device, main system software.
    [Show full text]
  • The 7 Dwarves: Debugging Information Beyond Gdb
    The 7 dwarves: debugging information beyond gdb Arnaldo Carvalho de Melo Red Hat, Inc. [email protected] [email protected] Abstract • To find out possibilities for reduction of such data structures; The DWARF debugging information format has been so • Use of information about function parameters and far used in debuggers such as gdb, and more recently in return types to generate Linux kernel modules for tools such as systemtap and frysk. obtaining data needed for generation of callgraphs In this paper the author will show additional scenarios and values set to fields at runtime; where such information can be useful, such as: • A tool that given two object files shows a binary diff to help understanding the effects of source • Showing the layout of data structures; code changes on size of functions and data struc- tures. • Reorganizing such data structures to remove align- ment holes; Some use cases will be presented, showing how the tools • Improving CPU cache utilization; can be used to solve real world problems. • Displaying statistics about inlining of functions; Ideas discussed with some fellow developers but not yet • Re-creating structs and functions from the debug- tried will also be presented, with the intent of hopefully ging information; having them finally tested in practice by interested read- ers. • Showing binary diffs to help understand the effects of any code change. 2 DWARF Debugging Format And much more. DWARF [3] is a debugging file format used by many compilers to store information about data structures, 1 Introduction variables, functions and other language aspects needed by high level debuggers.
    [Show full text]
  • Linking Basics.Docx Page 1 of 35 Initial Creation: March, 24, 2015 Date Updated: October 4, 2015
    An Overview of Object Files And Linking Harry H. Porter III Portland State University cs.pdx.edu/~harry April 9, 2015 Goals of this Paper Audience: CS-201 students Coverage: Compiling Linking Object files External Symbols Relocatable Code Segments (.text, .data., .bss) Filename: Linking Basics.docx Page 1 of 35 Initial Creation: March, 24, 2015 Date Updated: October 4, 2015 Overview In order to create an executable file, a program must be compiled and linked. In this paper, I’ll use the “C” programming language as an example, but this discussion applies to other compiled languages like C++. Languages that are interpreted (like Java or Python) do things differently and linking does not apply to them. We’ll also discuss the Linux/Unix system, but other OSes are similar. A program begins as a human readable source text file, such as “hello.c”. The program must first be compiled and this step produces a human readable text file in assembly code. Then the assembly code version is assembled and this produces an object file. Finally, the object file is linked and the executable file is produced. At some later time, the OS will load the executable file into memory run it. Many programs are large and these programs are broken into several “.c” files. We’ll look at an example involving two files, “hello.c” and “there.c”. Each of the .c files must be compiled and assembled, but these steps can be done independently. In other words, we can compile and assemble hello.c before we even create the there.c file.
    [Show full text]
  • Chapter 13 ARM Image Format
    Chapter 13 ARM Image Format This chapter describes the ARM Image Format (AIF). It contains the following sections: • Overview of the ARM Image Format on page 13-2 • AIF variants on page 13-3 • The layout of AIF on page 13-4. ARM DUI 0041C Copyright © 1997 and 1998 ARM Limited. All rights reserved. 13-1 ARM Image Format 13.1 Overview of the ARM Image Format ARM Image Format (AIF) is a simple format for ARM executable images, consisting of: • a 128-byte header • the image code • the image initialized static data. An AIF image is capable of self-relocation if it is created with the appropriate linker options. The image can be loaded anywhere and it will execute where it is loaded. After an AIF image has been relocated, it can create its own zero-initialized area. Finally, the image is entered at the unique entry point. 13-2 Copyright © 1997 and 1998 ARM Limited. All rights reserved. ARM DUI 0041C ARM Image Format 13.2 AIF variants There are three variants of AIF: Executable AIF Executable AIF can be loaded at its load address and entered at the same point (at the first word of the AIF header). It prepares itself for execution by relocating itself if required and setting to zero its own zero-initialized data. The header is part of the image itself. Code in the header ensures that the image is properly prepared for execution before being entered at its entry address. The fourth word of an executable AIF header is: BL entrypoint The most significant byte of this word (in the target byte order) is 0xeb.
    [Show full text]
  • Introduction to Computer Systems 15-213/18-243, Spring 2009
    Carnegie Mellon Linking 15-213: Introduction to Computer Systems 13th Lecture, February 23rd, 2016 Instructors: Franz Franchetti & Seth Copen Goldstein, Ralf Brown, and Brian Railing Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 1 Carnegie Mellon Today Linking Case study: Library interpositioning Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 2 Carnegie Mellon Example C Program int sum(int *a, int n); int sum(int *a, int n) { int array[2] = {1, 2}; int i, s = 0; int main() for (i = 0; i < n; i++) { { s += a[i]; int val = sum(array, 2); } return val; return s; } } main.c sum.c Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 3 Carnegie Mellon Static Linking Programs are translated and linked using a compiler driver: . linux> gcc -Og -o prog main.c sum.c . linux> ./prog main.c sum.c Source files Translators Translators (cpp, cc1, as) (cpp, cc1, as) main.o sum.o Separately compiled relocatable object files Linker (ld) Fully linked executable object file prog (contains code and data for all functions defined in main.c and sum.c) Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 4 Carnegie Mellon Why Linkers? Reason 1: Modularity . Program can be written as a collection of smaller source files, rather than one monolithic mass. Can build libraries of common functions (more on this later) . e.g., Math library, standard C library Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 5 Carnegie Mellon Why Linkers? (cont) Reason 2: Efficiency .
    [Show full text]
  • Linkers and Loaders Do?
    Linkers & Loaders by John R. Levine Table of Contents 1 Table of Contents Chapter 0: Front Matter ........................................................ 1 Dedication .............................................................................................. 1 Introduction ............................................................................................ 1 Who is this book for? ......................................................................... 2 Chapter summaries ............................................................................. 3 The project ......................................................................................... 4 Acknowledgements ............................................................................ 5 Contact us ........................................................................................... 6 Chapter 1: Linking and Loading ........................................... 7 What do linkers and loaders do? ............................................................ 7 Address binding: a historical perspective .............................................. 7 Linking vs. loading .............................................................................. 10 Tw o-pass linking .............................................................................. 12 Object code libraries ........................................................................ 15 Relocation and code modification .................................................... 17 Compiler Drivers .................................................................................
    [Show full text]