DOCSLIB.ORG

CS 5600 Computer Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
CS 5600 Computer Systems CS 5600 Computer Systems Programs, Processes, and Threads • Programs • Processes • Context Switching • Protected Mode Execu<on • Inter-process Communicaon • Threads 2 Running Dynamic Code • One basic func<on of an OS is to execute and manage code dynamically, e.g.: – A command issued at a command line terminal – An icon double clicKed from the desKtop – Jobs/tasKs run as part of a batch system (MapReduce) • A process is the basic unit of a program in execu<on 3 Programs and Processes Process The running instan<aon of a program, stored in RAM Program An executable file in long-term One-to-many storage relaonship between program and processes 4 How to Run a Program? • When you double-clicK on an .exe, how does the OS turn the file on disK into a process? • What informaon must the .exe file contain in order to run as a program? 5 Program Formats • Programs obey specific file formats – CP/M and DOS: COM executables (*.com) – DOS: MZ executables (*.exe) • Named aer MarK Zbikowski, a DOS developer – Windows Portable Executable (PE, PE32+) (*.exe) • Modified version of Unix COFF executable format • PE files start with an MZ header. Why? – Unix/Linux: Executable and LinKable Format (ELF) – Mac OSX: Mach object file format (Mach-O) 6 test.c #include <stdio.h> int big_big_array[10 * 1024 * 1024]; char *a_string = "Hello, World!"; int a_var_with_value = 100; int main(void) { big_big_array[0] = 100; prin("%s\n", a_string); a_var_with_value += 20; prin("main is : %p\n", &main); return 0; } 7 ELF File Format • ELF Header – Contains compability info – Entry point of the executable code • Program header table – Lists all the segments in the file – Used to load and execute the program • Sec<on header table – Used by the linKer 8 • Entry point of executable code • What should EIP be set to ini<ally? ELF Header Format typedef struct { 1 unsigned char e_ident[EI_NIDENT]; Elf32_Half e_type; 5 Elf32_Half e_machine; ISA of executable code Elf32_Word e_version; Elf32_Addr e_entry; Offset of program headers Elf32_Off e_phoff; Elf32_Off e_shoff; Offset of sec<on headers 10 Elf32_Word e_flags; Elf32_Half e_ehsize; Elf32_Half e_phentsize; # of program headers Elf32_Half e_phnum; Elf32_Half e_shentsize; # of sec<on headers 15 Elf32_Half e_shnum; Elf32_Half e_shstrndx; } Elf32_Ehdr; 9 ELF Header Example $ gcc –g –o test test.c $ readelf --header test ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, li{le endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x400460 Start of program headers: 64 (bytes into file) Start of sec<on headers: 5216 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 9 Size of sec<on headers: 64 (bytes) Number of sec<on headers: 36 Sec<on header string table index: 33 10 Inves<gang the Entry Point int main(void) { … prin("main is : %p\n", &main); return 0; } $ gcc -g -o test test.c $ readelf --headers ./test | grep Entry point' Entry point address: 0x400460 $ ./test Hello World! main is : 0x400544 11 Entry point != &main $ ./test • Most compilers insert extra Hello World! main is : 0x400544 code into compiled programs $ readelf --headers ./test | grep Entry point' • This code typically runs Entry point address: 0x400460 before and aer main() $ objdump --disassemble –M intel ./test … 0000000000400460 <_start>: 400460: 31 ed xor ebp,ebp 400462: 49 89 d1 mov r9,rdx 400465: 5e pop rsi 400466: 48 89 e2 mov rdx,rsp 400469: 48 83 e4 f0 and rsp,0xfffffffffffffff0 40046d: 50 push rax 40046e: 54 push rsp 40046f: 49 c7 c0 20 06 40 00 mov r8,0x400620 400476: 48 c7 c1 90 05 40 00 mov rcx,0x400590 40047d: 48 c7 c7 44 05 40 00 mov rdi,0x400544 400484: e8 c7 ff ff ff call 400450 <__libc_start_main@plt> … 12 Sec<ons and Segments Mul<ple sec<ons in • Secons are the various one segments pieces of code and data that get linKed together by the Segments compiler • Each segment contains one or more secons – Each segment contains sec<ons that are related • E.g. all code sec<ons – Segments are the basic units for the loader 13 Common Secons • Sec<ons are the various pieces of code and data that compose a program • Key secons: – .text – Executable code – .bss – Global variables ini<alized to zero – .data, .rodata – Ini<alized data and strings – .strtab – Names of func<ons and variables – .symtab – Debug symbols 14 String variable à .dataSec<on Example Empty 10 MB array à .bss int big_big_array[10*1024*1024]; char *a_string = "Hello, World!"; int a_var_with_value = 0x100; int main(void) { Ini<alized global variable à .data big_big_array[0] = 100; prin("%s\n", a_string); a_var_with_value += 20; … } String constant à .rodata Code à .text 15 $ readelf --headers ./test … Sec<on to Segment mapping: Segment Sec<ons... 00 01 .interp 02 .interp .note.ABI-tag .note.gnu.build- id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_fra me_hdr .eh_frame 03 .ctors .dtors .jcr .dynamic .got .got.plt .data .bss 04 .dynamic 05 .note.ABI-tag .note.gnu.build-id 06 .eh_frame_hdr 07 08 .ctors .dtors .jcr .dynamic .got … There are 36 sec<on headers, star<ng at offset 0x1460: Sec<on Headers: [Nr] Name Type Address Offset Size ES Flags Link Info Align [ 0] NULL 00000000 00000000 00000000 00 0 0 0 [ 1] .interp PROGBITS 00400238 00000238 0000001c 00 A 0 0 1 [ 2] .note.ABI-tag NOTE 00400254 00000254 00000020 00 A 0 0 4 [ 3] .note.gnu.build-I NOTE 00400274 00000274 00000024 00 A 0 0 4 [ 4] .gnu.hash GNU_HASH 00400298 00000298 0000001c 00 A 5 0 8 [ 5] .dynsym DYNSYM 004002b8 000002b8 00000078 18 A 6 1 8 [ 6] .dynstr STRTAB 00400330 00000330 00000044 00 A 0 0 1 [ 7] .gnu.version VERSYM 00400374 00000374 0000000a 02 A 5 0 2 … .text Example Header typedef struct { Elf32_Word p_type; Elf32_Off p_offset; Address to load 5 Elf32_Addr p_vaddr; secon in memory Elf32_Addr p_paddr; Elf32_Word p_filesz; Elf32_Word p_memsz; Offset of data in the file Elf32_Word p_flags; 10 Elf32_Word p_align; } How many bytes (in hex) Data for the are in the sec<on $program readelf --sec<ons ./test ... Sec<on Headers: Executable … [Nr] Name Type Address Offset Size ES Flags Link Info Align [13] .text PROGBITS 00400460 00000460 00000218 00 AX 0 0 16 … .bss Example Header int big_big_array[10*1024*1024]; typedef struct { Elf32_Word p_type; Offset of data in the file Elf32_Off p_offset; (No<ce the length = 0) 5 Elf32_Addr p_vaddr; Elf32_Addr p_paddr; Address to load Elf32_Word p_filesz; secon in memory Elf32_Word p_memsz; Elf32_Word p_flags; Contains 10 Elf32_Word p_align; no data } hex(4*10*1024*1024) = $ readelf --sec<ons ./test ... 0x2800020 Sec<on Headers: Writable … [Nr] Name Type Address Offset Size ES Flags Link Info Align [25] .bss NOBITS 00601040 00001034 02800020 00 WA 0 0 32 [26] .comment PROGBITS 00000000 00001034 000002a 01 MS 0 0 1 … Segments • Each segment contains one or more sec<ons – All of the sec<ons in a segment are related, e.g.: • All sec<ons contain compiled code • Or, all sec<ons contain ini<alized data • Or, all sec<ons contain debug informaon • … etc… • Segments are used by the loader to: – Place data and code in memory – Determine memory permissions (read/write/execute) 19 Segment Header typedef struct { Elf32_Word p_type; // Type of Segment Elf32_Off p_offset; // Offset for the segment 5 Elf32_Addr p_vaddr; // Locaon to load Elf32_Addr p_paddr; // the segmen<nto memory Elf32_Word p_filesz; // Size on disK Elf32_Word p_memsz; // Size in memory Elf32_Word p_flags; // Flags describing data 10 Elf32_Word p_align; } 20 $ readelf --segments ./test Elf file type is EXEC (Executable file) Entry point 0x400460 There are 9 program headers, star<ng at offset 64 Executable Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x00000040 0x00400040 0x00400040 0x000001f8 0x000001f8 R E 8 INTERP 0x00000238 0x00400238 0x00400238 0x0000001c 0x0000001c R 1 LOAD 0x00000000 0x00400000 0x00400000 0x0000077c 0x0000077c R E 200000 LOAD 0x00000e28 0x00600e28 0x00600e28 0x0000020c 0x02800238 RW 200000 DYNAMIC 0x00000e50 0x00600e50 0x00600e50 0x00000190 0x00000190 RW 8 NOTE 0x00000254 0x00400254 0x00400254 0x00000044 0x00000044 R 4 GNU_EH_FRAME 0x000006a8 0x004006a8 0x004006a8 0x0000002c 0x0000002c R 4 GNU_STACK 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 RW 8 GNU_RELRO 0x00000e28 0x00600e28 0x00600e28 0x000001d8 0x000001d8 R 1 Sec<on to Segment mapping: Segment Sec<ons... 00 01 .interp 02 .interp .note.ABI-tag .note.gnu.build- id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_fra me 03 .ctors .dtors .jcr .dynamic .got .got.plt .data .bss 04 .dynamic … What About Stac Data? #include <stdio.h> $ strings –t d ./test 568 /lib64/ld-linux-x86-64.so.2 int big_big_array[10 * 1024 * 1024]; 817 __gmon_start__ char *a_string = "Hello, World!"; 832 libc.so.6 842 puts int a_var_with_value = 100; 847 prin 854 __libc_start_main int main(void) { 872 GLIBC_2.2.5 big_big_array[0] = 100; 1300 fff. 1314 = prin("%s\n", a_string); 1559 l$ L a_var_with_value += 20; 1564 t$(L 1569 |$0H prin("main is : %p\n", &main); 1676 Hello, World! return 0; 1690 main is : %p 1807 ;*3$" } 22 Single-Process Address Space • The stacK is used for local variables and func<on calls Memory – Grows downwards StacK • Heap is allocated dynamically (malloc/ new) – Grows upwards Heap • When the stacK and heap meet, there is no more memory leZ in the process .bss – Process will probably crash .rodata .data
Load more

Recommended publications
  • The “Stabs” Debug Format
    The \stabs" debug format Julia Menapace, Jim Kingdon, David MacKenzie Cygnus Support Cygnus Support Revision TEXinfo 2017-08-23.19 Copyright c 1992{2021 Free Software Foundation, Inc. Contributed by Cygnus Support. Written by Julia Menapace, Jim Kingdon, and David MacKenzie. 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, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License". i Table of Contents 1 Overview of Stabs ::::::::::::::::::::::::::::::: 1 1.1 Overview of Debugging Information Flow ::::::::::::::::::::::: 1 1.2 Overview of Stab Format ::::::::::::::::::::::::::::::::::::::: 1 1.3 The String Field :::::::::::::::::::::::::::::::::::::::::::::::: 2 1.4 A Simple Example in C Source ::::::::::::::::::::::::::::::::: 3 1.5 The Simple Example at the Assembly Level ::::::::::::::::::::: 4 2 Encoding the Structure of the Program ::::::: 7 2.1 Main Program :::::::::::::::::::::::::::::::::::::::::::::::::: 7 2.2 Paths and Names of the Source Files :::::::::::::::::::::::::::: 7 2.3 Names of Include Files:::::::::::::::::::::::::::::::::::::::::: 8 2.4 Line Numbers :::::::::::::::::::::::::::::::::::::::::::::::::: 9 2.5 Procedures ::::::::::::::::::::::::::::::::::::::::::::::::::::: 9 2.6 Nested Procedures::::::::::::::::::::::::::::::::::::::::::::: 11 2.7 Block Structure
    [Show full text]
  • Portable Executable File Format
    Chapter 11 Portable Executable File Format IN THIS CHAPTER + Understanding the structure of a PE file + Talking in terms of RVAs + Detailing the PE format + The importance of indices in the data directory + How the loader interprets a PE file MICROSOFT INTRODUCED A NEW executable file format with Windows NT. This for- mat is called the Portable Executable (PE) format because it is supposed to be portable across all 32-bit operating systems by Microsoft. The same PE format exe- cutable can be executed on any version of Windows NT, Windows 95, and Win32s. Also, the same format is used for executables for Windows NT running on proces- sors other than Intel x86, such as MIPS, Alpha, and Power PC. The 32-bit DLLs and Windows NT device drivers also follow the same PE format. It is helpful to understand the PE file format because PE files are almost identi- cal on disk and in RAM. Learning about the PE format is also helpful for under- standing many operating system concepts. For example, how operating system loader works to support dynamic linking of DLL functions, the data structures in- volved in dynamic linking such as import table, export table, and so on. The PE format is not really undocumented. The WINNT.H file has several struc- ture definitions representing the PE format. The Microsoft Developer's Network (MSDN) CD-ROMs contain several descriptions of the PE format. However, these descriptions are in bits and pieces, and are by no means complete. In this chapter, we try to give you a comprehensive picture of the PE format.
    [Show full text]
  • Common Object File Format (COFF)
    Application Report SPRAAO8–April 2009 Common Object File Format ..................................................................................................................................................... ABSTRACT The assembler and link step create object files in common object file format (COFF). COFF is an implementation of an object file format of the same name that was developed by AT&T for use on UNIX-based systems. This format encourages modular programming and provides powerful and flexible methods for managing code segments and target system memory. This appendix contains technical details about the Texas Instruments COFF object file structure. Much of this information pertains to the symbolic debugging information that is produced by the C compiler. The purpose of this application note is to provide supplementary information on the internal format of COFF object files. Topic .................................................................................................. Page 1 COFF File Structure .................................................................... 2 2 File Header Structure .................................................................. 4 3 Optional File Header Format ........................................................ 5 4 Section Header Structure............................................................. 5 5 Structuring Relocation Information ............................................... 7 6 Symbol Table Structure and Content........................................... 11 SPRAAO8–April 2009
    [Show full text]
  • CS429: Computer Organization and Architecture Linking I & II
    CS429: Computer Organization and Architecture Linking I & II Dr. Bill Young Department of Computer Sciences University of Texas at Austin Last updated: April 5, 2018 at 09:23 CS429 Slideset 23: 1 Linking I A Simplistic Translation Scheme m.c ASCII source file Problems: Efficiency: small change Compiler requires complete re-compilation. m.s Modularity: hard to share common functions (e.g., printf). Assembler Solution: Static linker (or Binary executable object file linker). p (memory image on disk) CS429 Slideset 23: 2 Linking I Better Scheme Using a Linker Linking is the process of m.c a.c ASCII source files combining various pieces of code and data into a Compiler Compiler single file that can be loaded (copied) into m.s a.s memory and executed. Linking could happen at: Assembler Assembler compile time; Separately compiled m.o a.o load time; relocatable object files run time. Linker (ld) Must somehow tell a Executable object file module about symbols p (code and data for all functions defined in m.c and a.c) from other modules. CS429 Slideset 23: 3 Linking I Linking A linker takes representations of separate program modules and combines them into a single executable. This involves two primary steps: 1 Symbol resolution: associate each symbol reference throughout the set of modules with a single symbol definition. 2 Relocation: associate a memory location with each symbol definition, and modify each reference to point to that location. CS429 Slideset 23: 4 Linking I Translating the Example Program A compiler driver coordinates all steps in the translation and linking process.
    [Show full text]
  • 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.
    [Show full text]
  • Linking Basics.Docx Page 1 of 35 Initial Creation: March, 24, 2015 Date Updated: October 4, 2015
    An Overview of Object Files And Linking Harry H. Porter III Portland State University cs.pdx.edu/~harry April 9, 2015 Goals of this Paper Audience: CS-201 students Coverage: Compiling Linking Object files External Symbols Relocatable Code Segments (.text, .data., .bss) Filename: Linking Basics.docx Page 1 of 35 Initial Creation: March, 24, 2015 Date Updated: October 4, 2015 Overview In order to create an executable file, a program must be compiled and linked. In this paper, I’ll use the “C” programming language as an example, but this discussion applies to other compiled languages like C++. Languages that are interpreted (like Java or Python) do things differently and linking does not apply to them. We’ll also discuss the Linux/Unix system, but other OSes are similar. A program begins as a human readable source text file, such as “hello.c”. The program must first be compiled and this step produces a human readable text file in assembly code. Then the assembly code version is assembled and this produces an object file. Finally, the object file is linked and the executable file is produced. At some later time, the OS will load the executable file into memory run it. Many programs are large and these programs are broken into several “.c” files. We’ll look at an example involving two files, “hello.c” and “there.c”. Each of the .c files must be compiled and assembled, but these steps can be done independently. In other words, we can compile and assemble hello.c before we even create the there.c file.
    [Show full text]
  • Chapter 13 ARM Image Format
    Chapter 13 ARM Image Format This chapter describes the ARM Image Format (AIF). It contains the following sections: • Overview of the ARM Image Format on page 13-2 • AIF variants on page 13-3 • The layout of AIF on page 13-4. ARM DUI 0041C Copyright © 1997 and 1998 ARM Limited. All rights reserved. 13-1 ARM Image Format 13.1 Overview of the ARM Image Format ARM Image Format (AIF) is a simple format for ARM executable images, consisting of: • a 128-byte header • the image code • the image initialized static data. An AIF image is capable of self-relocation if it is created with the appropriate linker options. The image can be loaded anywhere and it will execute where it is loaded. After an AIF image has been relocated, it can create its own zero-initialized area. Finally, the image is entered at the unique entry point. 13-2 Copyright © 1997 and 1998 ARM Limited. All rights reserved. ARM DUI 0041C ARM Image Format 13.2 AIF variants There are three variants of AIF: Executable AIF Executable AIF can be loaded at its load address and entered at the same point (at the first word of the AIF header). It prepares itself for execution by relocating itself if required and setting to zero its own zero-initialized data. The header is part of the image itself. Code in the header ensures that the image is properly prepared for execution before being entered at its entry address. The fourth word of an executable AIF header is: BL entrypoint The most significant byte of this word (in the target byte order) is 0xeb.
    [Show full text]
  • 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]
  • Mach-O Internals
    Mach-O Internals William Woodru February 10, 2016 1 / 31 General Agenda 1. Who are you? 2. What is Mach-O? 3. An Extremely Brief History of Mach and Mach-O 4. Structure of a Mach-O File 5. Quirks Encountered 6. Concluding Notes 2 / 31 Who are you? My name is William Woodru. I'm a Computer Science major and Philosophy minor at the University of Maryland, College Park. Outside of school, I'm a member of the Homebrew project and a regular contributor to several open source groups. My work for Homebrew is largely concerned with the underlying system interface and reconciling OS X's intricacies/irregularities with the package manager. 3 / 31 What is Mach-O? Mach-O is the Mach Object binary format. Mach-O is used primarily by Apple in OS X and iOS. Apps on both platforms are really just directory trees containing Mach-O binaries and resources (fonts, icons, congurations). Metadata is stored in a number of places, but mainly within bundled plists (XML) and the binaries themselves. Like its cousins on Linux (ELF) and Windows (PE), Mach-O supports multiple object types: I Executable I Core dump I Shared library/object I Prelinked object le I etc. 4 / 31 . and multiple architectures: I m68k/m88k (yes, it's still supported!*) I x86 I AMD64 I POWER I ARMv6/7/8 Unlike ELF or PE, Mach-O has been extended to allow multi-architecture fat binaries. This has resulted in some interesting properties not shared by the other two. More on that later.
    [Show full text]
  • Compiler Driver
    GHS Compiler Driver Advanced Data Controls Corp. 1 Flow of Source Files Through the Tool Chain Assembly Language Sorce File Object Library Lnguage (Ada95,C,C++,Fortron,Pascal) Modules Archives Files Language Compiler Assembly Language File (.s extension) Assembled by the Assembler Object Module (.o extension) Linked Executable program a.out 2 Compiler Drivers • A compiler driver is a program which invokes the other components of the tool set to process a program. There is a separate compiler driver for each source language. The drivers use command line arguments and source file extensions to determine which compiler or assembler to invoke for each source file, then sequence the resulting output through the subsequent linker and conversion utilities, relieving the user of the burden of invoking each of these tools individually. 3 Compilers • Each Green Hills optimizing compiler is a combination of a language-specific front end, a global optimizer, and a target- specific code generator. Green Hills provides compilers for five languages: Ada,C,C++,FORTRAN,and Pascal, including all major dialects. All languages for a target use the same subroutine linkage conventions. This allows modules written in different languages to call each other. The compilers generate assembly language. 4 Assembler • The relocatable macro assembler translates assembly language statements and directives into a relocatable object file containing instructions and data. 5 Librarian • The Librarian combines object files created by assembler or Linker into a library file. The linker can search library files to resolve internal references. 6 Linker • The Linker combines one or more ELF object modules into a single ELF relocatable object or executable program.
    [Show full text]
  • Mach-O Programming Topics
    Mach-O Programming Topics Tools > Compiling & Debugging 2006-11-28 subsidiaries in the United States and other Apple Inc. countries. © 2003, 2006 Apple Computer, Inc. Java and all Java-based trademarks are All rights reserved. trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other No part of this publication may be countries. reproduced, stored in a retrieval system, or transmitted, in any form or by any means, PowerPC and and the PowerPC logo are mechanical, electronic, photocopying, trademarks of International Business recording, or otherwise, without prior Machines Corporation, used under license written permission of Apple Inc., with the therefrom. following exceptions: Any person is hereby UNIX is a registered trademark of The Open authorized to store documentation on a Group single computer for personal use only and Simultaneously published in the United to print copies of documentation for States and Canada. personal use provided that the documentation contains Apple’s copyright Even though Apple has reviewed this document, APPLE MAKES NO WARRANTY OR notice. REPRESENTATION, EITHER EXPRESS OR IMPLIED, WITH RESPECT TO THIS The Apple logo is a trademark of Apple Inc. DOCUMENT, ITS QUALITY, ACCURACY, MERCHANTABILITY, OR FITNESS FOR A Use of the “keyboard” Apple logo PARTICULAR PURPOSE. AS A RESULT, THIS (Option-Shift-K) for commercial purposes DOCUMENT IS PROVIDED “AS IS,” AND YOU, THE READER, ARE ASSUMING THE without the prior written consent of Apple ENTIRE RISK AS TO ITS QUALITY AND may constitute trademark infringement and ACCURACY. unfair competition in violation of federal IN NO EVENT WILL APPLE BE LIABLE FOR and state laws.
    [Show full text]
  • James Moscola Dept. of Engineering & Computer Science York College
    ECE260: Fundamentals of Computer Engineering Translation of High-Level Languages James Moscola Dept. of Engineering & Computer Science York College of Pennsylvania ECE260: Fundamentals of Computer Engineering Based on Computer Organization and Design, 5th Edition by Patterson & Hennessy Translation of High-Level Languages • Writing code in assembly is time consuming and can be challenging • A single line of C code may require many lines of assembly • Example: D[4 + i] = A[5 * j] + 6; • Must manage limited register set and stack • High-level languages exist to make programming computers easier • Abstract away many of the complexities of the underlying hardware • Increase programmer productivity • Compilers exist to automate translation from a high-level language into assembly • Typically integrated with an assembler and a linker to produce executable code ECE260: Fundamentals of Computer Engineering 2 Translation and Startup of a Program • Translation and startup of a program includes the following steps: • Programmer writes some code • Compiler translates code into assembly • Assembly is converted into an object file • Linker “stitches” together object files to produce an executable file • At a later time, when the executable file is executed • A loader loads the executable instructions and data into memory ECE260: Fundamentals of Computer Engineering 3 Compiling Code • Programmer may write code in multiple files Compiler Input and Output Files INPUT FILES OUTPUT FILES • Program written in C may include many main.c ➔ main.asm prog1.c ➔ prog1.asm
    [Show full text]