DOCSLIB.ORG

Evaluation of MIPS Prelinking

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Evaluation of MIPS Prelinking Evaluation of MIPS Prelinking Shin’ichi TSURUMOTO MITSUBISHI Electric Corporation Advanced Technology R&D Center Overview ♦ Obtained prelinker for MIPS, compiler and libraries, and ran them on our target board ♦ Measured application startup time on our target board, and verified that the prelinking is effective 2 CELF Embedded Linux Conference, April 18th, 2007 Background ♦ On June 2005, effectiveness of prelink technique was presented at CELF International Technical Conference in Yokohama ♦ On November 2005, I questioned on prelink on MIPS architecture at Tokyo Technical Jamboree ♦ On April 2006, I requested to implement prelink for MIPS at MIPS-SIG piggybacked on ELC (Worldwide Embedded Linux Conference) ♦ On July 2006, MIPS Technologies reported at Ottawa Linux Symposium that they have started to develop prelink ♦ On October 2006, MIPS Technologies and CodeSourcery reported at Tokyo Technical Jamboree that they completed the development 3 CELF Embedded Linux Conference, April 18th, 2007 What is Prelink? Without Prelink With Prelink Source Code Source Code Compile Compile Object File Object File Link Link Executable File Executable File Shared Library File Shared Library File Make ROM Image Prelink Executable File ( Resolved Addresses Attached ) ROM Image Shared Library File Make ROM Image Application Build Time ROM Image ROM Image ROM Image Mapping and Loading Executable Mapping and Loading Executable and Shared Library file and Shared Library file Improvement of Addresses of Symbols should Application Launch time be resolved by Dynamic Loader. Addresses are Already Resolved. Preparing Application execute Preparing Application execute RAM Image App. Shared Library RAM Image Run Time Addresses of Symbols Execute Application are needed for using Execute Application Shared Library Functions and Data. 4 CELF Embedded Linux Conference, April 18th, 2007 Effective Area of Prelinking h/w init Init scripts Boot-loader Initial application Kernel startup Applications w/o Prelink w Prelink Areas prelink is effective time Power on Startup complete 5 CELF Embedded Linux Conference, April 18th, 2007 Building MIPS Prelink Environment ♦ Obtaining patches ◊ prelink.tar.gz (svn://sourceware.org/svn/prelink) ◊ glibc-2.3.6-prelink.patch (sourceware.org/glibc) ◊ binutils-2.16.1-prelink.patch (sourceware.org) ♦ Applying patches and rebuilding toolchain ♦ Compiling prelink command (we built as self- prelinker on target) ♦ Building target image ♦ Executing prelink on target 6 CELF Embedded Linux Conference, April 18th, 2007 Target Environment ♦ CPU core： MIPS32(4KEc) ♦ Clock： 300MHz ♦ DRAM： 384MByte ♦ Flash： 64MByte 7 CELF Embedded Linux Conference, April 18th, 2007 Target of test 1 and 2 h/w init Init scripts Boot-loader Initial application Kernel startup Applications w/o Prelink w Prelink Application launch time time Power on Startup complete 8 CELF Embedded Linux Conference, April 18th, 2007 Test code 1(C) src-gen/main.c #include "incgen.h" ♦Compiled source code above so that each library function is an int main( int argc, char **argv ) independent shared library file { return 0; ♦Used GNU autotools to compile } ♦Witten shell script to form infinite inc-gen/incgen.h loop; measured time between start extern void func001(); and stop of the command with using extern void func002(); time command, repeating ten times to extern void func003(); get the average value : lib-gen/func001.c #include "incgen.h" #include#include "incgen.h" "incgen.h" void func01() {} voidvoid func01() func001() {} {} 9 CELF Embedded Linux Conference, April 18th, 2007 Test code 1(C++) src-gen/main.cpp #include "incgen.h" ♦Compiled source code above so that each library function is an int main( int argc, char **argv ) independent shared library file { return 0; ♦Used GNU autotools to compile } ♦Witten shell script to form infinite inc-gen/incgen.h loop; measured time between start extern void func001(); and stop of the command with using extern void func002(); time command, repeating ten times to extern void func003(); get the average value : lib-gen/func001.cpp #include "incgen.h" #include#include "incgen.h" "incgen.h" void func01() {} voidvoid func01() func001() {} {} Note: same test as of c edition, except for filename, extension and compiler 10 CELF Embedded Linux Conference, April 18th, 2007 Measurement of application launch time (C) 30 25 20 ec] s [ 15 e m i Without Prelink t 10 5 With Prelink 0 0 200 400 600 800 1000 1200 Links 11 CELF Embedded Linux Conference, April 18th, 2007 Measurement of application launch time (C++) 30 25 20 ec] Without Prelink s [ 15 e m i t 10 With Prelink 5 0 0 200 400 600 800 1000 1200 Links 12 CELF Embedded Linux Conference, April 18th, 2007 Measurement of application launch time 30 25 Without Prelink 20 C++ [sec] 15 e m i t C 10 With Prelink 5 0 0 200 400 600 800 1000 1200 Links 13 CELF Embedded Linux Conference, April 18th, 2007 Test Code 2 (C only) incgen.h extern int ival00001_00001; extern int ival00001_00002; : extern int ival00001_00010; extern void func00001_00001(); : extern void func00001_00002(); extern void func00001_00010(); extern int ival00002_00001; : Length of symbols libfilemmmmm.so libfilemmmmm.c : : #include#include "incgen.h""incgen.h" libfile00002.so libfile00002.c #include#include "incgen.h""incgen.h" libfile00001.so libfile00001.c #include#include "incgen.h""incgen.h" intint ival00001_00001;ival00001_00001; intint ival00001_00001; ival00001_00002; intintint ival00001_00001;ival00001_00001; ival00001_00002; intint ival00001_00001; ival00001_00002;: intint ival00001_00002;ival00001_00002;: int intival00001_00002; :ival00001_nnnnn; Number of lib files int: :ival00001_nnnnn; intint : ival00001_nnnnn;ival00001_nnnnn; intint ival00001_nnnnn;ival00001_nnnnn; Number of voidvoid func00001_00001()func00001_00001() {}{} global variables void func00001_00001() {} voidvoidvoid func00001_00001() func00001_00002()func00001_00002() {} {}{} in each lib file voidvoidvoid func00001_00001()func00001_00001() func00001_00002() {}{} {} void func00001_00002():: {} voidvoid func00001_00002()func00001_00002(): {}{} voidvoid: func00001_nnnnn()func00001_nnnnn() {}{} void:: func00001_nnnnn() {} Number of void func00001_nnnnn() {} voidvoid func00001_nnnnn()func00001_nnnnn() {}{} functions in each lib files 14 CELF Embedded Linux Conference, April 18th, 2007 Launch time dependency 12 •Number of functions : 30 10 •Number of global variables : 30 •Length of symbols : 15 8 ec] s [ 6 e Without Prelink m Ti 4 2 With Prelink 0 0 200 400 600 800 Number of lib files 15 CELF Embedded Linux Conference, April 18th, 2007 Launch time dependency 1.2 Without Prelink 1 0.8 ec] s [ 0.6 e With Prelink m Ti 0.4 •Number of lib files : 200 0.2 •Number of global variables : 30 •Length of symbols : 15 0 0 20406080100120 Number of functions in each lib file 16 CELF Embedded Linux Conference, April 18th, 2007 Launch time dependency 1.2 Without Prelink 1 0.8 ec] s [ 0.6 e With Prelink m Ti 0.4 •Number of lib files : 200 0.2 •Number of functions : 30 •Length of symbols : 15 0 0 20406080100120 Number of global variables in each lib files 17 CELF Embedded Linux Conference, April 18th, 2007 Launch time dependency 1.2 Without Prelink 1 0.8 ec] s [ 0.6 e With Prelink m i T 0.4 •Number of lib files : 200 0.2 •Number of functions : 30 •Number of global variables : 30 0 0 50 100 150 200 250 Length of symbols 18 CELF Embedded Linux Conference, April 18th, 2007 Target of test 3 (C++ only) Saving of 1.68sec h/w init Initial application Boot-loader Init scripts Kernel startup Applications w/o Prelink 3.86sec 2.18sec w Prelink Areas prelink is effective time Power on Startup complete 19 CELF Embedded Linux Conference, April 18th, 2007 Test 3; Measurement of System Startup Time ♦ At the top of the init script, just after mounting the procfs, write out contents of /proc/uptime onto a temporary file ♦ At the beginning of first invoked application, just after the completion of init script, got the value of /proc/uptime; measured the time elapsed from init script to the invocation of the first application by comparing the obtained value and the saved value ♦ Time saving of 1.68 sec observed for startup time it run through busybox 8 times (3.86sec -> 2.18sec) 20 CELF Embedded Linux Conference, April 18th, 2007 Conclusion ♦ We verified Prelinker for MIPS ♦ We observed the improvement of 0.92sec -> 0.49 sec (C) and 1.88 sec -> 0.70 sec (C++) with 200 links ♦ Application startup time increases exponentially with number of links ♦ More improvement of application startup time was observed for C++ than for C 21 CELF Embedded Linux Conference, April 18th, 2007 Special Thanks ♦ MIPS Technologies ♦ CodeSourcery ♦ MIPS-SIG Members (CE-Linux Forum) 22 CELF Embedded Linux Conference, April 18th, 2007 Thank You !!! 23 CELF Embedded Linux Conference, April 18th, 2007.
Load more

Recommended publications
  • Red Hat Enterprise Linux 6 Developer Guide
    Red Hat Enterprise Linux 6 Developer Guide An introduction to application development tools in Red Hat Enterprise Linux 6 Dave Brolley William Cohen Roland Grunberg Aldy Hernandez Karsten Hopp Jakub Jelinek Developer Guide Jeff Johnston Benjamin Kosnik Aleksander Kurtakov Chris Moller Phil Muldoon Andrew Overholt Charley Wang Kent Sebastian Red Hat Enterprise Linux 6 Developer Guide An introduction to application development tools in Red Hat Enterprise Linux 6 Edition 0 Author Dave Brolley [email protected] Author William Cohen [email protected] Author Roland Grunberg [email protected] Author Aldy Hernandez [email protected] Author Karsten Hopp [email protected] Author Jakub Jelinek [email protected] Author Jeff Johnston [email protected] Author Benjamin Kosnik [email protected] Author Aleksander Kurtakov [email protected] Author Chris Moller [email protected] Author Phil Muldoon [email protected] Author Andrew Overholt [email protected] Author Charley Wang [email protected] Author Kent Sebastian [email protected] Editor Don Domingo [email protected] Editor Jacquelynn East [email protected] Copyright © 2010 Red Hat, Inc. and others. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
    [Show full text]
  • 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]
  • 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]
  • Improving Security Through Egalitarian Binary Recompilation
    Improving Security Through Egalitarian Binary Recompilation David Williams-King Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy under the Executive Committee of the Graduate School of Arts and Sciences COLUMBIA UNIVERSITY 2021 © 2021 David Williams-King All Rights Reserved Abstract Improving Security Through Egalitarian Binary Recompilation David Williams-King In this thesis, we try to bridge the gap between which program transformations are possible at source-level and which are possible at binary-level. While binaries are typically seen as opaque artifacts, our binary recompiler Egalito (ASPLOS 2020) enables users to parse and modify stripped binaries on existing systems. Our technique of binary recompilation is not robust to errors in disassembly, but with an accurate analysis, provides near-zero transformation overhead. We wrote several demonstration security tools with Egalito, including code randomization, control-flow integrity, retpoline insertion, and a fuzzing backend. We also wrote Nibbler (ACSAC 2019, DTRAP 2020), which detects unused code and removes it. Many of these features, including Nibbler, can be combined with other defenses resulting in multiplicatively stronger or more effective hardening. Enabled by our recompiler, an overriding theme of this thesis is our focus on deployable software transformation. Egalito has been tested by collaborators across tens of thousands of Debian programs and libraries. We coined this term egalitarian in the context of binary security. Simply put, an egalitarian analysis or security mechanism is one that can operate on itself (and is usually more deployable as a result). As one demonstration of this idea, we created a strong, deployable defense against code reuse attacks.
    [Show full text]
  • Chapter 1. Origins of Mac OS X
    1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
    [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]
  • CIS Ubuntu Linux 18.04 LTS Benchmark
    CIS Ubuntu Linux 18.04 LTS Benchmark v1.0.0 - 08-13-2018 Terms of Use Please see the below link for our current terms of use: https://www.cisecurity.org/cis-securesuite/cis-securesuite-membership-terms-of-use/ 1 | P a g e Table of Contents Terms of Use ........................................................................................................................................................... 1 Overview ............................................................................................................................................................... 12 Intended Audience ........................................................................................................................................ 12 Consensus Guidance ..................................................................................................................................... 13 Typographical Conventions ...................................................................................................................... 14 Scoring Information ..................................................................................................................................... 14 Profile Definitions ......................................................................................................................................... 15 Acknowledgements ...................................................................................................................................... 17 Recommendations ............................................................................................................................................
    [Show full text]
  • Linux Fundamentals Paul Cobbaut Linux Fundamentals Paul Cobbaut
    Linux Fundamentals Paul Cobbaut Linux Fundamentals Paul Cobbaut Publication date 2015-05-24 CEST Abstract This book is meant to be used in an instructor-led training. For self-study, the intent is to read this book next to a working Linux computer so you can immediately do every subject, practicing each command. This book is aimed at novice Linux system administrators (and might be interesting and useful for home users that want to know a bit more about their Linux system). However, this book is not meant as an introduction to Linux desktop applications like text editors, browsers, mail clients, multimedia or office applications. More information and free .pdf available at http://linux-training.be . Feel free to contact the author: • Paul Cobbaut: [email protected], http://www.linkedin.com/in/cobbaut Contributors to the Linux Training project are: • Serge van Ginderachter: [email protected], build scripts and infrastructure setup • Ywein Van den Brande: [email protected], license and legal sections • Hendrik De Vloed: [email protected], buildheader.pl script We'd also like to thank our reviewers: • Wouter Verhelst: [email protected], http://grep.be • Geert Goossens: [email protected], http://www.linkedin.com/in/ geertgoossens • Elie De Brauwer: [email protected], http://www.de-brauwer.be • Christophe Vandeplas: [email protected], http://christophe.vandeplas.com • Bert Desmet: [email protected], http://blog.bdesmet.be • Rich Yonts: [email protected], Copyright 2007-2015 Netsec BVBA, Paul Cobbaut Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
    [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]
  • 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]
  • 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]
  • [Improving System Performance Using Application-Level Hints]
    Improving System Performance using Application-Level Hints Björn Döbel Technische Universität Dresden, Department of Computer Science, Operating Systems Group 8th June 2005 Supervising professor: Prof. Dr. Hermann Härtig Supervisor: Dipl.-Inf. Martin Pohlack Selbständigkeitserklärung Hiermit erkläre ich, die vorliegende Arbeit selbständig verfasst zu haben. Ich habe keine anderen als die im Quellenverzeichnis angegebenen Literaturhilfsmittel verwendet. Dresden, 08.06.2005 Björn Döbel 2 Contents 1 Introduction 5 1.1 State of the art .................................. 6 1.1.1 Monitoring ............................... 7 1.1.2 Resource management ......................... 8 1.1.3 Linux kernel modules ......................... 9 1.1.4 Caches in Linux ............................ 10 1.1.5 Using prefetching to increase application performance ........ 11 1.2 Related work .................................. 14 1.2.1 Transparent Informed Prefetch ..................... 14 1.2.2 Speculative Hinting ........................... 15 1.2.3 Integrating prefetching and caching .................. 16 2 Design 19 2.1 Disk accesses and application startup ...................... 19 2.2 Design goals ................................... 20 2.3 Design decisions ................................ 21 2.3.1 Collecting data ............................. 21 2.3.2 Modifying the Linux kernel ...................... 23 2.3.3 HintMod - the kernel module ...................... 24 2.3.4 HintGen - the hint generator ...................... 25 2.3.5 Application of hints .........................
    [Show full text]