DOCSLIB.ORG

Post-Assembly Program Relocation Relocation Dictionary (RLD) and External Symbol Dictionary (ESD)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Post-Assembly Program Relocation Relocation Dictionary (RLD) and External Symbol Dictionary (ESD) Post-assembly Program Relocation Relocation Dictionary (RLD) and External Symbol Dictionary (ESD) 1. Terminology: Relocatable vs. not Relocatable "relocatable" refers to something that can be moved without adjustment; i.e., the program semantics are not changed by moving the item. To say something is not relocatable means that if you move it, you will have to adjust it. For simple SIC most instructions use absolute referencing, and so most operands are not relocatable. In contrast, most SIC/XE operands are relocatable, the exception being 4-byte instructions, which usually have operands that are not relocatable. Symbols such as statement labels and self-defining literals have a value that is relative to the START statement. These are called relative references. When a relative reference is used in an absolute context, it is not relocatable; e.g., for +LDA #STUFF the operand STUFF (which is a relative reference) is not relocatable. A reference whose value does not depend on the START statement is called an absolute reference. Actual numbers are always absolute references, so in contrast, +LDA #1234 has a relocatable operand. Note that LDA 1234 is relocatable for either simple SIC or SIC/SE. 2. Load Process The initial load process for a relocating loader is the same as that for an absolute loader (such as the one used for the SIC Simulator); i.e., the loader simply loads the object module into memory starting from a specified memory location. For an absolute loader, this location is specified as part of the load module and since the assembler has determined all addresses in the module using this location, no addressing adjustments are required. For a relocating loader, the memory location is not specified until load time (presumably provided by the operating system or some other control program); i.e., the binding of the load module to a specific load location in memory is not determined until the time of load. Since this location was not known at the time the object module was assembled, any absolute references in the object code must be adjusted to reflect the load location in order for the loaded code to work as planned. This process is called program relocation. 3. Relocation Dictionary (RLD) If programs are to be dynamically relocated in memory, the assembler must generate a table of those program locations that are not relocatable, called the Relocation Dictionary or RLD. For discussion purposes, we assume that the program START is 0. It is a simple adjustment otherwise. The RLD is used by the loader, which (for a START of 0) simply adds the program load point to the value pointed to by each (relative) location specified in the RLD. In contrast to SIC/XE, where most operands are relocatable, the RLD for a simple SIC program would need to specify almost every instruction. The RLD is normally generated "on the fly" during pass 2 of the assembler, with each entry derived from the current value of the location counter. The only information needed in an RLD entry is the (relative) location of the 3-byte word within the object module that needs to be adjusted for the object code to work. In particular, for the most common case in SIC/XE, a 4-byte instruction with a non-relocatable operand, the assembler simply adds locctr + 1 to the RLD as part of the process of generating code for the instruction. Note that it is during code generation that the assembler determines if generated code is relocatable or non- relocatable. Example: Assume that the WORD storage directive allows symbolic references in the operand field and suppose that a program has the following lines: loc assembly language statement object code 2B1 LOOP LDB ADDR,X 6BA010 . 2C4 ADDR WORD STUFF 0052A1 . 410C +JSUB LOOP 4B1002B1 4110 +LDB #12345 6B103039 . 52A1 STUFF RESW 12000 Since LOOP is a label in a program, then the statement +JSUB LOOP has a relative reference (LOOP) used in an absolute context and so it is not "relocatable". This is determined during code generation in pass 2 and the location of the operand 410C+1 = 00410D is added to the RLD. In contrast, for the statement +LDB #12345 the operand is absolute, so no RLD entry is generated. For the statement ADDR WORD STUFF the relative reference STUFF also occurs in an absolute context, which means that the 3-byte word generated by the assembler is not relocatable. Hence, the location for this particular WORD directive needs to be added to the RLD. Just as with "+" instructions, this is normally determined "on the fly" during pass 2 of the assembler, in this case when the WORD statement is resolved. The location counter points directly to the location of the operand; hence, the value 0002C4 is added to the RLD (which for this example also happens to be the value of ADDR). 4. Externally Defined Symbols, Control Sections (CSECT) Suppose that a program consists of a main routine and 2 subroutines and that these are being written independently. In order to assemble these routines, the source files must essentially be amalgamated, because each may use symbolic references defined in one of the other routines. As program size increases, the need to be able to work with subroutines and assemble them independently increases, so it is advantageous to automate this process. The mechanism employed is that of a control section (CSECT). A control section is a block of code that can be assembled independently. The first line of the block is <label> CSECT <initial-locctr> The block ends when the END statement or another CSECT is encountered. The START statement serves as the first CSECT. If a CSECT is labeled, the label is usually referred to as the name of the control section. If no initial location counter is provided, assembly starts from 0 for the control section. Since it can be assembled independently, each control section has its own RLD. There are two types of symbolic references used in a control section: 1. symbols defined in the control section that are referenced only within the section (local symbols) 2. symbols used in the control section that are not defined within the section (externally defined symbols) A local symbol name may appear in more than one control section since its reference within the section is unambiguous. Example: P 87 5. EXTREF and EXTDEF statements An externally defined symbol used within a control section must be identified by using EXTREF statements within the control section; e.g., EXTREF SUB1, SUB2 The EXTREF only needs to be issued before first use of the symbol in an operand, although good form is to place all EXTREF statements at the beginning of the CSECT. It is an error for a control section to have an EXTREF for a symbol that is also defined within the section. A control section identifies symbols that are to be made available to other controls sections by using EXTDEF statements; e.g., EXTDEF TABSIZE, ADDR1 If there is a label on the CSECT statement, it is automatically included as an EXTDEF (i.e., specification as EXTDEF is inferred). 6. External Symbol Dictionary (ESD) The RLD provides the information needed for the loader to relocate a control section. The means for dealing with externally defined symbols is called the external symbol dictionary or ESD. In contrast to the RLD, the ESD for each control section must contain both symbolic and location information. There are 2 basic parts to the ESD: 1. EXTDEF Part: finalized in pass 1 as pairs consisting of (<EXTDEF-symbol>, <value>) [<value> = value of the symbol in the symbol table] 2. EXTREF Part: finalized in pass 2 as triples consisting of (<EXTREF-symbol>, <location>, <operation>) [<location> = (relative) location of operand referencing the symbol] [<operation> = +, -, *, / ] Example: EXTDEF part Given a control section labeled SUB1, EXTDEF TABSIZE, ADDR1 might generate as the EXTDEF part of the ESD the table: SUB1 000000 TABSIZE 0000F3 ADDR1 0000DD where each EXTDEF address is taken straight from the symbol table at the end of pass 1. Each entry in the EXTDEF part of an ESD provides the value of a symbolic reference. It is an error if a symbol appears in the EXTDEF part of more than one ESD. Note that the references in the EXTDEF part are not relocatable; i.e., their values must be adjusted at load time by adding on the load point for their associated module. The EXTDEF part is set up by EXTDEF statements and can be finished at the end of pass 1. In contrast, the EXTREF part can only be constructed incrementally as external operands are encountered during pass 2 code generation. At module load time, each location in the EXTREF part must be adjusted by adding on the load point for the associated module (as is also the case for the EXTDEF part). If operand arithmetic is not supported, the <operation> entry is redundant (defaults to "+"), because the value of the external reference, once known, is just added to the 3-byte value at the operand location. Example: EXTREF part Suppose that TABSIZE is an EXTREF for some module, and the assembler (in pass 2) encounters the statement +LDA TABSIZE with location counter at 12B. The pass 2 object code line generated is then 03100000 and the entry for the EXTREF part of the ESD is TABSIZE 00012C + (the operand is at locctr+1) In essence, in generating the object code, the external reference to TABSIZE in this example is treated as an absolute reference (0), to be resolved at load time once the (relocated) value of TABSIZE becomes known.
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]
  • 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) .
    [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]