DOCSLIB.ORG

Zygote Anatomy Based on Prelink & Preload for Android Platform

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Zygote Anatomy Based on Prelink & Preload for Android Platform 23-Oct(Fri) , 2009 ZygoteZygote AnatomyAnatomy BasedBased onon PrelinkPrelink && PreloadPreload forfor AndroidAndroid PlatformPlatform 4th Korea Android Seminar GeunSik Lim [email protected] http://blog.naver.com/invain 4th Korea Android Seminar 1/53 Agenda 1. Dynamic Linking & Static Linking 2. Prelink Fundamentals 3. Understanding Preload 4. Custom Linker (=Android Prelink) 5. Zygote Walkthrough 6. Relation between process and thread by Zygote 4th Korea Android Seminar 2/53 Main Keywords in This Session Dynamic Linking Prelink Prefetch Custom Linker Static Preread for Android Linking P rel oad Zygote Prefork Dynamic Loading 4th Korea Android Seminar 3/53 Location of Linker in FOSS World 4th Korea Android Seminar 4/53 Static Linking • Static linking avoids dependency problems. (-static) • In general cases, static linking can result in a performance improvement. • Static linking can also allow the application to be contained in a single executable file, simplifying distribution and installation. • In static linking, the size of the executable becomes greater than in dynamic linking, as the library code is stored within the executable rather than in separate files. 4th Korea Android Seminar 5/53 Dynamic Linking • Libraries can be integrated into a program once by a linker. Dynamic linking has advantages in code size and management. ( -dynamic) • But, every time a program is run, the loader needs to find the relevant libraries. • Because 1) the libraries can move around in memory, this causes a performance penalty, 2) and the more libraries that need to be resolved, the greater the penalty. 4th Korea Android Seminar 6/53 Dynamic loading with Linux • Programming Interface : dlopen( ), dlsym( ), dlclose( ), dlerror( ) • Load the math library, and print the cosine of 2.0 #include stdio.h , stdlib.h , dlfcn.h int main (int argc, char **argv) { void *handle; double (*cosine)(double); char *error; handle = dlopen("libm.so", RTLD_LAZY); if (!handle) { fprintf(stderr, "%s\n", dlerror()); exit(EXIT_FAILURE); } dlerror(); /* Clear any existing error */ *(void **) (&cosine) = dlsym(handle, "cos"); if ((error = dlerror()) != NULL) { fprintf(stderr, "%s\n", error); exit(EXIT_FAILURE); } printf(“Consine is %f\n", (*cosine)(2.0)); dlclose(handle); exit(EXIT_SUCCESS); } 4th Korea Android Seminar 7/53 Static vs. dynamic Static Linux libraries Dynamic Loading Shared Dynamic Linking Program X Program Y Static libraries Static libraries Static linking ( *.a ) ( *.a ) Static linking At compile-time (init daemon of Android) Program X Program Y Shared libraries Dynamic linking ( *.so ) Dynamic linking Dynamic Of shared libraries At run-time 4th Korea Android Seminar 8/53 Source Compile Process cpp0 PreProcesser cc1 C Compiler Assembler ld or collect2 Hello.c Linker C Source Hello.i ProProcess Result Hello.s Assembly File Hello.o Object File Hello ELF --save-temps ADT JAVA Compiler DX Utility with .XML & .ARSC Eclipse .java (Source Code) .class file (Byte Code) .dex like exe on Dalvik VM .apk Decompiler (Interpreter) (e.g: Decafe , DJ Java) 4th Korea Android Seminar 9/53 Preload • Files of more frequently-used programs are, during a computer's spare time, loaded into memory. • This results in faster (speed up) application startup times as less data needs to be fetched from disk. /lib/libc.so.6 /lib/libcom_err.so.2 /lib/libcrypt.so.1 Preload /lib/libcrypto.so.6 /lib/libdb-4.3.so /lib/libdbus-1.so.3 /lib/libdl.so.2 /lib/libexpat.so.0 /lib/libglib-2.0.so.0 /lib/libgmodule-2.0.so.0 /lib/libgobject-2.0.so.0 /lib/libgthread-2.0.so.0 . Below Omission . rams used prog frequently- 4th Korea Android Seminar 10/5 3 Readahead Daemon for Preload • The readahead reads the contents of a list of files into memory, which causes them to be read from cache when they are actually needed. Its goal is to speed up the boot process. • e.g) Readahead daemon for Linux distribution - An adaptive prefetching daemon - http://sourceforge.net/projects/preload/ #> /usr/sbin/readahead `cat /etc/readahead.early.files` & - A list of files cached in the memory lsof / | grep -v "^₩(lsof₩|grep₩)" | awk '{ print $4 " " $9 }' | grep ^mem ₩ | awk '{ print $2 }' |grep -v "^.₩(var₩|tmp₩|home₩|root₩)" | grep ^[/] | sort -u if (fd >= 0) { readahead(fd, offset, length); close (fd); } 4th Korea Android Seminar 11/53 What is Prelink? • A tool designed to speed up dynamic linking of ELF programs. (e.g: ELF shared libraries and ELF dynamically linked binaries) • To speed up a system by reducing the time a program needs to begin. • A FOSS is written by Jakub Jelinek of Red Hat. F11#> svn checkout http://sourceware.org/svn/prelink/trunk prelink • Process on Mac OS X is called "prebinding". 4th Korea Android Seminar 12/53 Merits of Prelink • Dynamic linker needs for their relocation at startup significantly decreases. • The run-time memory consumption decreases too according to fewer relocations. ☎ Prelinked system fedora11$> LD_DEBUG=statistics firefox 2>&1 | sed ’s/ˆ *//’ 25733: runtime linker statistics: 25733: total startup time in dynamic loader: 5533696 clock cycles 25733: time needed for relocation: 1941529 clock cycles (35.0%) 25733: number of relocations: 0 25733: number of relocations from cache: 2066 25733: number of relative relocations: 0 25733: time needed to load objects: 3217736 clock cycles (58.1%) 25733: runtime linker statistics: 25733: final number of relocations: 0 25733: final number of relocations from cache: 2066 4th Korea Android Seminar 13/53 Prelink Map Application Process Global Dynamic Loader Linkage Table Offset Table PLT Slot Got Entry dl_runtime_resolve JMP GOT[1] GOT[1] dl_runtime_resolve {{ JMP GOT[2] GOT[2] . .. .. JMP GOT[3] GOT[3] . ④ call func_a(); . call func_a(); } ... JMP GOT[4] GOT[4] ③ } ...... ② ... call func_b(); JMP GOT[5] GOT[5] call func_b();... ① ... JMP GOT[6] GOT[6] ... Symbol Table call func_c();... call func_c(); JMP GOT[7] GOT[7] ... Lazy Binding ...... func_a . ⑦ . func_a call func_d();... 0x12345678 ... call func_d();... ... ... JMP GOT[N-2] GOT[N-2] ... ... ... ... Symbol JMP GOT[N-1] GOT[N-1] func_bfunc_b ...Lookup JMP GOT[N] GOT[N] ⑧ ... ⑤ func_cfunc_c Update GOT LookUp Address ...... (Relocation) ⑥ ss of e Addre Absolut bole 4th Korea Android Seminar Sym 14/53 Prelink on X86 Desktop 1/2 prelink-no#> yum -y install prelink ( ubuntu#> apt-get –y install prelink ) prelink-no#> prelink ./firefox prelink-yes#> time LD_DEBUG=statistics DISPLAY= LD_LIBRARY_PATH=. ./firefox real 7m0.261s user 4m0.026s sys 1m0.082s prelink-yes#> prelink --undo ./firefox prelink-no#> time LD_DEBUG=statistics DISPLAY= LD_LIBRARY_PATH=. ./firefox Speed Up real 9m1.342s user 5m6.024s sys 1m5.052s 4th Korea Android Seminar 15/53 Prelink on X86 Desktop 2/2 • Appended Section Headers After Prelink : .gnu_liblist , .gnu_conflict, .gnu_prelink_undo 4th Korea Android Seminar 16/53 Why do you need Prelink? • prelink reduces this penalty by using the system's dynamic linker to reversibly perform this linking in advance by relocating. • Afterward, the program only needs to spend time finding the relevant libraries on being run if, for some reason (perhaps an upgrade), the libraries have changed since being prelinked. • In Android Platform, The need for Almost all the local symbols ( 80-90 % of the symbols in .rel.dyn and .rel.plt) and it gives much quicker performance. In Summary, In order to reduce size and speed up loading. 4th Korea Android Seminar 17/53 F11#> export LANG=C F11#> man 2 dlopen F11#> man 3 exec Diff Between Prelink and Preload in Mobile • Prelink for prelinked binary execution model for fork and exec model. • Preload for non-prelinked binary execution model for fork and dlopen model. • Hybrid for pre-linked binary execution model for fork and dlopen model. Zygote ile ob M r Fo Ref) Hybrid related Paper : Performance Characterization of Prelinking and Preloading for Embedded Systems 4th Korea Android Seminar 18/53 Memory Layout of Pre-linked Libraries Prelinked libraries can only be loaded at the very specific virtual memory address they have been prelinked to (during the build process). The list of prelinked system libraries and their corresponding virtual memory address is found in the below file. ./build/core/prelink-linux-arm.map # 0xC0000000 - 0xFFFFFFFF Kernel # 0xB0100000 - 0xBFFFFFFF Thread 0 Stack # 0xB0000000 - 0xB00FFFFF Linker # 0xA0000000 - 0xBFFFFFFF Prelinked System Libraries # 0x90000000 - 0x9FFFFFFF Prelinked App Libraries # 0x80000000 - 0x8FFFFFFF Non-prelinked Libraries # 0x40000000 - 0x7FFFFFFF mmap'd stuff # 0x10000000 - 0x3FFFFFFF Thread Stacks # 0x00000000 - 0x0FFFFFFF .text / .data / heap • #define PRELINK_MIN 0x90000000 • #define PRELINK_MAX 0xB0000000 4th Korea Android Seminar 19/53 Prelinked System Libraries 01. Core System Libraries (libdl, libc, libstdc++, libm, liblog, libcutils, libthread_db, libz, libevent, libssl, libcrypto, libsysutils) 02. Bluetooth (liba2dp, audio, input, libhcid, libbluedroid, libbluetooth, libdbus) 03. Extended system libraries ( libril, libreference-ril, libwpa_client, libnetutils) 04. Core dalvik runtime support (libicuuc, libicui18n, libandroid-runtime, libnativehelper, libdvm-ARM, libdvm) 05. Graphics ( libpixelflinger, libcorecg, libsurfaceflinger, libagl, libGLESv1_CM, libGLESv2, libOpenVG_CM, libOpenVGU_CM, libEGL, libexif, libui, libsgl) 06. Audio 07. Assorted System libraries 08. PV opencore libraries 09. Opencore hardware support 10. PV libraries 4th Korea Android Seminar 20/53 Prelinked Application Libraries 01. libraries for specific apps or temporary ( libcam_ipl, libwbxml, libwbxml_jni, libxml2wbxml,
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]