DOCSLIB.ORG

Linker and Libraries Guide

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Linker and Libraries Guide Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054 U.S.A. Part No: 816–7777–10 April 2003 Copyright 2003 Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers. Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd. Sun, Sun Microsystems, the Sun logo, docs.sun.com, AnswerBook, AnswerBook2, and Solaris are trademarks, registered trademarks, or service marks of Sun Microsystems, Inc. in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. The OPEN LOOK and Sun™ Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun’s licensees who implement OPEN LOOK GUIs and otherwise comply with Sun’s written license agreements. Federal Acquisitions: Commercial Software–Government Users Subject to Standard License Terms and Conditions. DOCUMENTATION IS PROVIDED “AS IS” AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. Copyright 2003 Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 U.S.A. Tous droits réservés. Ce produit ou document est protégé par un copyright et distribué avec des licences qui en restreignent l’utilisation, la copie, la distribution, et la décompilation. Aucune partie de ce produit ou document ne peut être reproduite sous aucune forme, par quelque moyen que ce soit, sans l’autorisation préalable et écrite de Sun et de ses bailleurs de licence, s’il y en a. Le logiciel détenu par des tiers, et qui comprend la technologie relative aux polices de caractères, est protégé par un copyright et licencié par des fournisseurs de Sun. Des parties de ce produit pourront être dérivées du système Berkeley BSD licenciés par l’Université de Californie. UNIX est une marque déposée aux Etats-Unis et dans d’autres pays et licenciée exclusivement par X/Open Company, Ltd. Sun, Sun Microsystems, le logo Sun, docs.sun.com, AnswerBook, AnswerBook2, et Solaris sont des marques de fabrique ou des marques déposées, ou marques de service, de Sun Microsystems, Inc. aux Etats-Unis et dans d’autres pays. Toutes les marques SPARC sont utilisées sous licence et sont des marques de fabrique ou des marques déposées de SPARC International, Inc. aux Etats-Unis et dans d’autres pays. Les produits portant les marques SPARC sont basés sur une architecture développée par Sun Microsystems, Inc. L’interface d’utilisation graphique OPEN LOOK et Sun™ a été développée par Sun Microsystems, Inc. pour ses utilisateurs et licenciés. Sun reconnaît les efforts de pionniers de Xerox pour la recherche et le développement du concept des interfaces d’utilisation visuelle ou graphique pour l’industrie de l’informatique. Sun détient une licence non exclusive de Xerox sur l’interface d’utilisation graphique Xerox, cette licence couvrant également les licenciés de Sun qui mettent en place l’interface d’utilisation graphique OPEN LOOK et qui en outre se conforment aux licences écrites de Sun. CETTE PUBLICATION EST FOURNIE “EN L’ETAT” ET AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, N’EST ACCORDEE, Y COMPRIS DES GARANTIES CONCERNANT LA VALEUR MARCHANDE, L’APTITUDE DE LA PUBLICATION A REPONDRE A UNE UTILISATION PARTICULIERE, OU LE FAIT QU’ELLE NE SOIT PAS CONTREFAISANTE DE PRODUIT DE TIERS. CE DENI DE GARANTIE NE S’APPLIQUERAIT PAS, DANS LA MESURE OU IL SERAIT TENU JURIDIQUEMENT NUL ET NON AVENU. 030224@5533 Contents Preface 13 1 Introduction to the Solaris Linkers 17 Link-Editing 18 Runtime Linking 19 Related Topics 20 Dynamic Linking 20 Application Binary Interfaces 20 32–Bit and 64–Bit Environments 20 Environment Variables 21 Support Tools 21 2 Link-Editor 23 Invoking the Link-Editor 24 Direct Invocation 24 Using a Compiler Driver 25 Specifying the Link-Editor Options 25 Input File Processing 26 Archive Processing 27 Shared Object Processing 28 Linking With Additional Libraries 29 Initialization and Termination Sections 34 Symbol Processing 36 Symbol Resolution 36 Undefined Symbols 40 3 Tentative Symbol Order Within the Output File 44 Defining Additional Symbols 44 Reducing Symbol Scope 49 External Bindings 53 String Table Compression 54 Generating the Output File 54 Relocation Processing 55 Displacement Relocations 56 Debugging Aids 57 3 Runtime Linker 61 Shared Object Dependencies 62 Locating Shared Object Dependencies 62 Directories Searched by the Runtime Linker 62 Configuring the Default Search Paths 65 Dynamic String Tokens 65 Relocation Processing 66 Symbol Lookup 67 When Relocations Are Performed 68 Relocation Errors 70 Loading Additional Objects 71 Lazy Loading of Dynamic Dependencies 72 Initialization and Termination Routines 74 Initialization and Termination Order 75 Security 77 Runtime Linking Programming Interface 79 Loading Additional Objects 80 Relocation Processing 81 Obtaining New Symbols 87 Feature Checking 90 Debugging Aids 90 Debugging Library 90 Debugger Module 93 4 Shared Objects 97 Naming Conventions 98 Recording a Shared Object Name 99 4 Linker and Libraries Guide • April 2003 Shared Objects With Dependencies 101 Dependency Ordering 102 Shared Objects as Filters 103 Generating a Standard Filter 103 Generating an Auxiliary Filter 106 Filtee Processing 107 Performance Considerations 107 Analyzing Files 108 Underlying System 109 Lazy Loading of Dynamic Dependencies 110 Position-Independent Code 110 Remove Unused Material 113 Maximizing Shareability 113 Minimizing Paging Activity 115 Relocations 115 Using -Bsymbolic 120 Profiling Shared Objects 120 5 Application Binary Interfaces and Versioning 123 Interface Compatibility 124 Internal Versioning 125 Creating a Version Definition 125 Binding to a Version Definition 130 Specifying a Version Binding 134 Version Stability 138 Relocatable Objects 139 External Versioning 139 Coordination of Versioned Filenames 139 6 Support Interfaces 143 Link-Editor Support Interface 143 Invoking the Support Interface 144 Support Interface Functions 145 Support Interface Example 147 Runtime Linker Auditing Interface 149 Establishing a Namespace 150 Creating an Audit Library 150 Contents 5 Invoking the Auditing Interface 151 Recording Local Auditors 152 Audit Interface Functions 152 Audit Interface Example 157 Audit Interface Demonstrations 157 Audit Interface Limitations 158 Runtime Linker Debugger Interface 158 Interaction Between Controlling and Target Process 159 Debugger Interface Agents 160 Debugger Exported Interface 161 Debugger Import Interface 169 7 Object File Format 171 File Format 171 Data Representation 173 ELF Header 174 ELF Identification 178 Data Encoding 180 Sections 181 Section Groups 192 Special Sections 193 String Table 198 Symbol Table 199 Syminfo Table 206 Relocation 208 Comdat Section 218 Versioning Information 218 Note Section 223 Move Section 224 Thread-Local Storage 226 Dynamic Linking 227 Program Header 228 Program Loading (Processor-Specific) 233 Runtime Linker 239 Dynamic Section 240 Global Offset Table (Processor-Specific) 252 Procedure Linkage Table (Processor-Specific) 253 6 Linker and Libraries Guide • April 2003 Hash Table 261 8 Mapfile Option 263 Mapfile Structure and Syntax 263 Segment Declarations 264 Mapping Directives 268 Section-Within-Segment Ordering 269 Size-Symbol Declarations 270 File Control Directives 270 Mapping Example 270 Mapfile Option Defaults 272 Internal Map Structure 273 A Link-Editor Quick Reference 277 Static Mode 277 Creating a Relocatable Object 278 Creating a Static Executable 278 Dynamic Mode 278 Creating a Shared Object 278 Creating a Dynamic Executable 280 B Versioning Quick Reference 281 Naming Conventions 281 Defining a Shared Object’s Interface 283 Versioning a Shared Object 283 Versioning an Existing (Non-versioned) Shared Object 284 Updating a Versioned Shared Object 285 Adding New Symbols 285 Internal Implementation Changes 286 New Symbols and Internal Implementation Changes 286 Migrating Symbols to a Standard Interface 287 C Establishing Dependencies with Dynamic String Tokens 291 Instruction Set Specific Shared Objects 291 Reducing Auxiliary Searches 292 System Specific Shared Objects 293 Contents 7 Locating Associated Dependencies 293 Dependencies Between Unbundled Products 295 Security 296 D New Linker and Libraries Features and Updates 299 Solaris 9 12/02 Release 299 Solaris 9 Release 299 Solaris 8 07/01 Release 300 Solaris 8 01/01 Release 300 Solaris 8 10/00 Release 301 Solaris 8 Release 301
Recommended publications
  • Introduction to Computer Systems 15-213/18-243, Spring 2009 1St

    Introduction to Computer Systems 15-213/18-243, Spring 2009 1St

    M4-L3: Executables CSE351, Winter 2021 Executables CSE 351 Winter 2021 Instructor: Teaching Assistants: Mark Wyse Kyrie Dowling Catherine Guevara Ian Hsiao Jim Limprasert Armin Magness Allie Pfleger Cosmo Wang Ronald Widjaja http://xkcd.com/1790/ M4-L3: Executables CSE351, Winter 2021 Administrivia ❖ Lab 2 due Monday (2/8) ❖ hw12 due Friday ❖ hw13 due next Wednesday (2/10) ▪ Based on the next two lectures, longer than normal ❖ Remember: HW and readings due before lecture, at 11am PST on due date 2 M4-L3: Executables CSE351, Winter 2021 Roadmap C: Java: Memory & data car *c = malloc(sizeof(car)); Car c = new Car(); Integers & floats c->miles = 100; c.setMiles(100); x86 assembly c->gals = 17; c.setGals(17); Procedures & stacks float mpg = get_mpg(c); float mpg = Executables free(c); c.getMPG(); Arrays & structs Memory & caches Assembly get_mpg: Processes pushq %rbp language: movq %rsp, %rbp Virtual memory ... Memory allocation popq %rbp Java vs. C ret OS: Machine 0111010000011000 100011010000010000000010 code: 1000100111000010 110000011111101000011111 Computer system: 3 M4-L3: Executables CSE351, Winter 2021 Reading Review ❖ Terminology: ▪ CALL: compiler, assembler, linker, loader ▪ Object file: symbol table, relocation table ▪ Disassembly ▪ Multidimensional arrays, row-major ordering ▪ Multilevel arrays ❖ Questions from the Reading? ▪ also post to Ed post! 4 M4-L3: Executables CSE351, Winter 2021 Building an Executable from a C File ❖ Code in files p1.c p2.c ❖ Compile with command: gcc -Og p1.c p2.c -o p ▪ Put resulting machine code in
  • CERES Software Bulletin 95-12

    CERES Software Bulletin 95-12

    CERES Software Bulletin 95-12 Fortran 90 Linking Experiences, September 5, 1995 1.0 Purpose: To disseminate experience gained in the process of linking Fortran 90 software with library routines compiled under Fortran 77 compiler. 2.0 Originator: Lyle Ziegelmiller ([email protected]) 3.0 Description: One of the summer students, Julia Barsie, was working with a plot program which was written in f77. This program called routines from a graphics package known as NCAR, which is also written in f77. Everything was fine. The plot program was converted to f90, and a new version of the NCAR graphical package was released, which was written in f77. A problem arose when trying to link the new f90 version of the plot program with the new f77 release of NCAR; many undefined references were reported by the linker. This bulletin is intended to convey what was learned in the effort to accomplish this linking. The first step I took was to issue the "-dryrun" directive to the f77 compiler when using it to compile the original f77 plot program and the original NCAR graphics library. "- dryrun" causes the linker to produce an output detailing all the various libraries that it links with. Note that these libaries are in addition to the libaries you would select on the command line. For example, you might compile a program with erbelib, but the linker would have to link with librarie(s) that contain the definitions of sine or cosine. Anyway, it was my hypothesis that if everything compiled and linked with f77, then all the libraries must be contained in the output from the f77's "-dryrun" command.
  • Download Article (PDF)

    Download Article (PDF)

    Proceedings of the 2nd International Conference on Computer Science and Electronics Engineering (ICCSEE 2013) SecGOT: Secure Global Offset Tables in ELF Executables Chao Zhang, Lei Duan, Tao Wei, Wei Zou Beijing Key Laboratory of Internet Security Technology Institute of Computer Science and Technology, Peking University Beijing, China {chao.zhang, lei_duan, wei_tao, zou_wei}@pku.edu.cn Abstract—Global Offset Table (GOT) is an important feature library code for these two processes are different). This to support library sharing in Executable and Linkable Format problem also restrains the code sharing feature of libraries. (ELF) applications. The addresses of external modules’ global A solution called PIC (Position Independent Code [3]) is variables and functions are runtime resolved and stored in the proposed for the ELF (Executable and Linkable Format [4]) GOT and then are used by the program. If attackers tamper executable binaries which are common in Linux. with the function pointers in the GOT, they can hijack the In libraries or main modules supporting PIC, the code program’s control flow and execute arbitrary malicious code. section does not reference any absolute addresses in order to Current research pays few attentions on this threat (i.e. GOT support code sharing between processes. However, absolute hijacking attack). In this paper, we proposed and implemented addresses are unavoidable in programs. As a result, a GOT a protection mechanism SecGOT to randomize the GOT at table (Global Offset Table [4]) is introduced in the library. load time, and thus prevent attackers from guessing the GOT’s position and tampering with the function pointers. SecGOT is This table resides in the data section and is not shared evaluated against 101 binaries in the /bin directory for Linux.
  • Linking + Libraries

    Linking + Libraries

    LinkingLinking ● Last stage in building a program PRE- COMPILATION ASSEMBLY LINKING PROCESSING ● Combining separate code into one executable ● Linking done by the Linker ● ld in Unix ● a.k.a. “link-editor” or “loader” ● Often transparent (gcc can do it all for you) 1 LinkingLinking involves...involves... ● Combining several object modules (the .o files corresponding to .c files) into one file ● Resolving external references to variables and functions ● Producing an executable file (if no errors) file1.c file1.o file2.c gcc file2.o Linker Executable fileN.c fileN.o Header files External references 2 LinkingLinking withwith ExternalExternal ReferencesReferences file1.c file2.c int count; #include <stdio.h> void display(void); Compiler extern int count; int main(void) void display(void) { file1.o file2.o { count = 10; with placeholders printf(“%d”,count); display(); } return 0; Linker } ● file1.o has placeholder for display() ● file2.o has placeholder for count ● object modules are relocatable ● addresses are relative offsets from top of file 3 LibrariesLibraries ● Definition: ● a file containing functions that can be referenced externally by a C program ● Purpose: ● easy access to functions used repeatedly ● promote code modularity and re-use ● reduce source and executable file size 4 LibrariesLibraries ● Static (Archive) ● libname.a on Unix; name.lib on DOS/Windows ● Only modules with referenced code linked when compiling ● unlike .o files ● Linker copies function from library into executable file ● Update to library requires recompiling program 5 LibrariesLibraries ● Dynamic (Shared Object or Dynamic Link Library) ● libname.so on Unix; name.dll on DOS/Windows ● Referenced code not copied into executable ● Loaded in memory at run time ● Smaller executable size ● Can update library without recompiling program ● Drawback: slightly slower program startup 6 LibrariesLibraries ● Linking a static library libpepsi.a /* crave source file */ … gcc ..
  • Using the DLFM Package on the Cray XE6 System

    Using the DLFM Package on the Cray XE6 System

    Using the DLFM Package on the Cray XE6 System Mike Davis, Cray Inc. Version 1.4 - October 2013 1.0: Introduction The DLFM package is a set of libraries and tools that can be applied to a dynamically-linked application, or an application that uses Python, to provide improved performance during the loading of dynamic libraries and importing of Python modules when running the application at large scale. Included in the DLFM package are: a set of wrapper functions that interface with the dynamic linker (ld.so) to cache the application's dynamic library load operations; and a custom libpython.so, with a set of optimized components, that caches the application's Python import operations. 2.0: Dynamic Linking and Python Importing Without DLFM When a dynamically-linked application is executed, the set of dependent libraries is loaded in sequence by ld.so prior to the transfer of control to the application's main function. This set of dependent libraries ordinarily numbers a dozen or so, but can number many more, depending on the needs of the application; their names and paths are given by the ldd(1) command. As ld.so processes each dependent library, it executes a series of system calls to find the library and make the library's contents available to the application. These include: fd = open (/path/to/dependent/library, O_RDONLY); read (fd, elfhdr, 832); // to get the library ELF header fstat (fd, &stbuf); // to get library attributes, such as size mmap (buf, length, prot, MAP_PRIVATE, fd, offset); // read text segment mmap (buf, length, prot, MAP_PRIVATE, fd, offset); // read data segment close (fd); The number of open() calls can be many times larger than the number of dependent libraries, because ld.so must search for each dependent library in multiple locations, as described on the ld.so(1) man page.
  • Environment Variable and Set-UID Program Lab 1

    Environment Variable and Set-UID Program Lab 1

    SEED Labs – Environment Variable and Set-UID Program Lab 1 Environment Variable and Set-UID Program Lab Copyright © 2006 - 2016 Wenliang Du, All rights reserved. Free to use for non-commercial educational purposes. Commercial uses of the materials are prohibited. The SEED project was funded by multiple grants from the US National Science Foundation. 1 Overview The learning objective of this lab is for students to understand how environment variables affect program and system behaviors. Environment variables are a set of dynamic named values that can affect the way running processes will behave on a computer. They are used by most operating systems, since they were introduced to Unix in 1979. Although environment variables affect program behaviors, how they achieve that is not well understood by many programmers. As a result, if a program uses environment variables, but the programmer does not know that they are used, the program may have vulnerabilities. In this lab, students will understand how environment variables work, how they are propagated from parent process to child, and how they affect system/program behaviors. We are particularly interested in how environment variables affect the behavior of Set-UID programs, which are usually privileged programs. This lab covers the following topics: • Environment variables • Set-UID programs • Securely invoke external programs • Capability leaking • Dynamic loader/linker Readings and videos. Detailed coverage of the Set-UID mechanism, environment variables, and their related security problems can be found in the following: • Chapters 1 and 2 of the SEED Book, Computer & Internet Security: A Hands-on Approach, 2nd Edition, by Wenliang Du.
  • Chapter 6: the Linker

    Chapter 6: the Linker

    6. The Linker 6-1 Chapter 6: The Linker References: • Brian W. Kernighan / Dennis M. Ritchie: The C Programming Language, 2nd Ed. Prentice-Hall, 1988. • Samuel P. Harbison / Guy L. Steele Jr.: C — A Reference Manual, 4th Ed. Prentice-Hall, 1995. • Online Documentation of Microsoft Visual C++ 6.0 (Standard Edition): MSDN Library: Visual Studio 6.0 release. • Horst Wettstein: Assemblierer und Binder (in German). Carl Hanser Verlag, 1979. • Peter Rechenberg, Gustav Pomberger (Eds.): Informatik-Handbuch (in German). Carl Hanser Verlag, 1997. Kapitel 12: Systemsoftware (H. M¨ossenb¨ock). Stefan Brass: Computer Science III Universit¨atGiessen, 2001 6. The Linker 6-2 Overview ' $ 1. Introduction (Overview) & % 2. Object Files, Libraries, and the Linker 3. Make 4. Dynamic Linking Stefan Brass: Computer Science III Universit¨atGiessen, 2001 6. The Linker 6-3 Introduction (1) • Often, a program consists of several modules which are separately compiled. Reasons are: The program is large. Even with fast computers, editing and compiling a single file with a million lines leads to unnecessary delays. The program is developed by several people. Different programmers cannot easily edit the same file at the same time. (There is software for collaborative work that permits that, but it is still a research topic.) A large program is easier to understand if it is divided into natural units. E.g. each module defines one data type with its operations. Stefan Brass: Computer Science III Universit¨atGiessen, 2001 6. The Linker 6-4 Introduction (2) • Reasons for splitting a program into several source files (continued): The same module might be used in different pro- grams (e.g.
  • Csc 453 Linking and Loading

    Csc 453 Linking and Loading

    CSc 453 Linking and Loading Saumya Debray The University of Arizona Tucson Tasks in Executing a Program 1. Compilation and assembly. Translate source program to machine language. The result may still not be suitable for execution, because of unresolved references to external and library routines. 2. Linking. Bring together the binaries of separately compiled modules. Search libraries and resolve external references. 3. Loading. Bring an object program into memory for execution. Allocate memory, initialize environment, maybe fix up addresses. CSc 453: Linking and Loading 2 1 Contents of an Object File Header information Overall information about the file and its contents. Object code and data Relocations (may be omitted in executables) Information to help fix up the object code during linking. Symbol table (optional) Information about symbols defined in this module and symbols to be imported from other modules. Debugging information (optional) CSc 453: Linking and Loading 3 Example: ELF Files (x86/Linux) Linkable sections Executable segments ELF Header Program Header (optional, ignored) describes sections Table sections segments Section Header describes sections (optional, ignored) Table CSc 453: Linking and Loading 4 2 ELF Files: contcont’’’’dddd ELF Header structure 16 bytes ELF file identifying information (magic no., addr size, byte order) 2 bytes object file type (relocatable, executable, shared object, etc.) 2 bytes machine info 4 bytes object file version 4 bytes entry point (address where execution begins) 4 bytes offset of program header table 4 bytes offset of section header table 4 bytes processor-specific flags 2 bytes ELF header size (in bytes) 2 bytes size of each entry in program header table 2 bytes no.
  • GNU GCC Compiler

    GNU GCC Compiler

    C-Refresher: Session 01 GNU GCC Compiler Arif Butt Summer 2017 I am Thankful to my student Muhammad Zubair [email protected] for preparation of these slides in accordance with my video lectures at http://www.arifbutt.me/category/c-behind-the-curtain/ Today’s Agenda • Brief Concept of GNU gcc Compiler • Compilation Cycle of C-Programs • Contents of Object File • Multi-File Programs • Linking Process • Libraries Muhammad Arif Butt (PUCIT) 2 Compiler Compiler is a program that transforms the source code of a high level language into underlying machine code. Underlying machine can be x86 sparse, Linux, Motorola. Types of Compilers: gcc, clang, turbo C-compiler, visual C++… Muhammad Arif Butt (PUCIT) 3 GNU GCC Compiler • GNU is an integrated distribution of compilers for C, C++, OBJC, OBJC++, JAVA, FORTRAN • gcc can be used for cross compile Cross Compile: • Cross compile means to generate machine code for the platform other than the one in which it is running • gcc uses tools like autoConf, automake and lib to generate codes for some other architecture Muhammad Arif Butt (PUCIT) 4 Compilation Process Four stages of compilation: •Preprocessor •Compiler •Assembler •Linker Muhammad Arif Butt (PUCIT) 5 Compilation Process(cont...) hello.c gcc –E hello.c 1>hello.i Preprocessor hello.i 1. Preprocessor • Interpret Preprocessor Compiler directives • Include header files • Remove comments • Expand headers Assembler Linker Muhammad Arif Butt (PUCIT) 6 Compilation Process(cont...) hello.c 2. Compiler • Check for syntax errors Preprocessor • If no syntax error, the expanded code is converted to hello.i assembly code which is understood by the underlying Compiler gcc –S hello.i processor, e.g.
  • An-572 Application Note

    An-572 Application Note

    AN-572 a APPLICATION NOTE One Technology Way • P.O. Box 9106 • Norwood, MA 02062-9106 • 781/329-4700 • World Wide Web Site: http://www.analog.com Overlay Linking on the ADSP-219x By David Starr OVERVIEW the linker. Having a number of memories to deal with This applications note is for software designers starting makes the DSP linker somewhat more complex than an ADSP-219x overlay design. Using this note and the linkers for Princeton architecture machines. information in the Linker and Utilities Manual for ADSP- In addition, each DSP project must fit into a different 21xx Family DSPs the following may be done: memory arrangement. Different DSP boards have differ- Divide a program into overlays. ent amounts of memory, located at different addresses. Write LDF files for simple and overlay links. The ADSP-219x family supports an external memory Write an overlay manager. interface, allowing rather large amounts of memory, but at a penalty in speed. Internal memory is ten times faster HARVARD VS. PRINCETON ARCHITECTURE AND THE than external memory, so it may be desirable to keep LINKER large amounts of program code in external memory Early in the history of computing, the modern design of swap parts of it to internal memory for speed in execu- one memory to hold both data and program instructions tion. Such a program is said to run in “overlays.” acquired the name “Princeton.” Such a machine is flex- For code reuse and portability, a program should not ible because programs with lots of code and little data require modification to run in different machines or in work, as well as programs with little code and lots of different locations in memory.
  • An Efficient Protocol for Linker Scanning Mutagenesis: Analysis of the Translational Regulation of an Escherichia Coli RNA Polymerase Subunit Gene Derek M

    An Efficient Protocol for Linker Scanning Mutagenesis: Analysis of the Translational Regulation of an Escherichia Coli RNA Polymerase Subunit Gene Derek M

    1997 Oxford University Press Nucleic Acids Research, 1997, Vol. 25, No. 21 4209–4218 An efficient protocol for linker scanning mutagenesis: analysis of the translational regulation of an Escherichia coli RNA polymerase subunit gene Derek M. Dykxhoorn, Rebecca St. Pierre, Oded Van Ham and Thomas Linn* Department of Microbiology and Immunology, Faculty of Medicine, University of Western Ontario, London, Ontario N6A 5C1, Canada Received August 18, 1997; Accepted September 12, 1997 ABSTRACT of the synthetic linker. Though effective, this approach involves a number of time consuming steps. Many deletions have to be A protocol has been developed that is capable of generated and sequenced before appropriate 5′ and 3′ combinations saturating regions hundreds of basepairs in length can be identified, followed by a separate ligation for each 5′/3′ pair with linker scanning mutations. The efficacy of this to produce the final linker scanning mutation. method stems from the design of the linker scanning We have developed a more efficient protocol for linker scanning mutagenesis (LSM) cassette which is composed of a mutagenesis that is capable of generating a library consisting of selectable marker flanked by two oligonucleotides, hundreds of mutations. This protocol makes use of a linker scanning each of which contains a recognition site for a different mutagenesis (LSM) cassette which is composed of two synthetic restriction endonuclease. The cleavage site for one oligonucleotides surrounding the selectable tetracycline resistance endonuclease is within its recognition site, while the gene. The oligonucleotide on one side of the tetracycline resistance second endonuclease cleaves in the target DNA gene has the recognition site for SmaI, while the other beyond the end of the cassette.
  • Dynamic Linking Considered Harmful

    Dynamic Linking Considered Harmful

    DYNAMIC LINKING CONSIDERED HARMFUL 1 WHY WE NEED LINKING ¡ Want to access code/data defined somewhere else (another file in our project, a library, etc) ¡ In compiler-speak, “we want symbols with external linkage” § I only really care about functions here ¡ Need a mechanism by which we can reference symbols whose location we don’t know ¡ A linker solves this problem. Takes symbols annotated by the compiler (unresolved symbols) and patches them 2 DYNAMIC LINKING ¡ We want to: ¡ use code defined somewhere else, but we don’t want to have to recompile/link when it’s updated ¡ be able to link only those symbols used as runtime (deferred/lazy linking) ¡ be more efficient with resources (may get to this later) 3 CAVEATS ¡ Applies to UNIX, particularly Linux, x86 architecture, ELF Relevant files: -glibcX.X/elf/rtld.c -linux-X.X.X/fs/exec.c, binfmt_elf.c -/usr/include/linux/elf.h ¡ (I think) Windows linking operates similarly 4 THE BIRTH OF A PROCESS 5 THE COMPILER ¡ Compiles your code into a relocatable object file (in the ELF format, which we’ll get to see more of later) ¡ One of the chunks in the .o is a symbol table ¡ This table contains the names of symbols referenced and defined in the file ¡ Unresolved symbols will have relocation entries (in a relocation table) 6 THE LINKER ¡ Patches up the unresolved symbols it can. If we’re linking statically, it has to fix all of them. Otherwise, at runtime ¡ Relocation stage. Will not go into detail here. § Basically, prepares program segments and symbol references for load time 7 THE SHELL fork(), exec() 8 THE KERNEL (LOADER) ¡ Loaders are typically kernel modules.