DOCSLIB.ORG

Cs61c/Su06 CS61C : Machine Structures Lecture #13: CALL

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Cs61c/Su06 CS61C : Machine Structures Lecture #13: CALL inst.eecs.berkeley.edu/~cs61c/su06 CS61C : Machine Structures Lecture #13: CALL 2006-07-19 Andy Carle CS 61C L13 CALL (1) A Carle, Summer 2006 © UCB CALL Overview • Interpretation vs Translation • Translating C Programs • Compiler • Assembler • Linker • Loader • An Example CS 61C L13 CALL (2) A Carle, Summer 2006 © UCB Interpretation vs Translation • How do we run a program written in a source language? • Interpreter: Directly executes a program in the source language • Translator: Converts a program from the source language to an equivalent program in another language CS 61C L13 CALL (3) A Carle, Summer 2006 © UCB Language Continuum Scheme Java Assembly C++ C machine language Easy to write Difficult to write Inefficient to run Efficient to run • Interpret a high level language if efficiency is not critical • Translate (compile) to a lower level language to improve performance • Scheme example … CS 61C L13 CALL (4) A Carle, Summer 2006 © UCB Interpretation Scheme program: foo.scm Scheme Interpreter CS 61C L13 CALL (5) A Carle, Summer 2006 © UCB Translation Scheme program: foo.scm Scheme Compiler Executable(mach lang pgm): a.out Hardware °Scheme Compiler is a translator from Scheme to machine language. CS 61C L13 CALL (6) A Carle, Summer 2006 © UCB Interpretation • Any good reason to interpret machine language in software? • SPIM – useful for learning / debugging • Apple Macintosh conversion • Switched from Motorola 680x0 instruction architecture to PowerPC. • Could require all programs to be re- translated from high level language • Instead, let executables contain old and/or new machine code, interpret old code in software if necessary CS 61C L13 CALL (7) A Carle, Summer 2006 © UCB Interpretation vs. Translation? • Easier to write interpreter • Interpreter closer to high-level, so gives better error messages (e.g., SPIM) • Translator reaction: add extra information to help debugging (line numbers, names) • Interpreter slower (10x?) but code is smaller (1.5X to 2X?) • Interpreter provides instruction set independence: run on any machine • See Apple example CS 61C L13 CALL (8) A Carle, Summer 2006 © UCB Steps to Starting a Program C program: foo.c Compiler Assembly program: foo.s Assembler Object(mach lang module): foo.o Linker lib.o Executable(mach lang pgm): a.out Loader Memory CS 61C L13 CALL (9) A Carle, Summer 2006 © UCB Compiler • Input: High-Level Language Code (e.g., C, Java such as foo.c) • Output: Assembly Language Code (e.g., foo.s for MIPS) • Note: Output may contain pseudoinstructions • Pseudoinstructions: instructions that assembler understands but not in machine (last lecture) For example: • mov $s1,$s2 ⇒ or $s1,$s2,$zero CS 61C L13 CALL (10) A Carle, Summer 2006 © UCB Where Are We Now? C program: foo.c Compiler Assembly program: foo.s Assembler Object(mach lang module): foo.o Linker lib.o Executable(mach lang pgm): a.out Loader Memory CS 61C L13 CALL (11) A Carle, Summer 2006 © UCB Assembler • Input: MAL Assembly Language Code (e.g., foo.s for MIPS) • Output: Object Code, information tables (e.g., foo.o for MIPS) • Reads and Uses Directives • Replace Pseudoinstructions • Produce Machine Language • Creates Object File CS 61C L13 CALL (12) A Carle, Summer 2006 © UCB Assembler Directives (p. A-51 to A-53) • Give directions to assembler, but do not produce machine instructions .text: Subsequent items put in user text segment .data: Subsequent items put in user data segment .globl sym: declares sym global and can be referenced from other files .asciiz str: Store the string str in memory and null-terminate it .word w1…wn: Store the n 32-bit quantities in successive memory words CS 61C L13 CALL (13) A Carle, Summer 2006 © UCB Pseudoinstruction Replacement • Asm. treats convenient variations of machine language instructions as if real instructions Pseudo: Real: subu $sp,$sp,32 addiu $sp,$sp,-32 sd $a0, 32($sp) sw $a0, 32($sp) sw $a1, 36($sp) mul $t7,$t6,$t5 mult $t6,$t5 mflo $t7 addu $t0,$t6,1 addiu $t0,$t6,1 ble $t0,100,loop slti $at,$t0,101 bne $at,$0,loop la $a0, str lui $at,left(str) ori $a0,$at,right(str) CS 61C L13 CALL (14) A Carle, Summer 2006 © UCB Producing Machine Language (1/3) • Constraint on Assembler: • The object file output (foo.o) may be only one of many object files in the final executable: - C: #include “my_helpers.h” - C: #include <stdio.h> • Consequences: • Object files won’t know their base addresses until they are linked/loaded! • References to addresses will have to be adjusted in later stages CS 61C L13 CALL (15) A Carle, Summer 2006 © UCB Producing Machine Language (2/3) • Simple Case • Arithmetic, Logical, Shifts, and so on. • All necessary info is within the instruction already. • What about Branches? • PC-Relative and in-file • In TAL, we know by how many instructions to branch. • So these can be handled easily. CS 61C L13 CALL (16) A Carle, Summer 2006 © UCB Producing Machine Language (3/3) • What about jumps (j and jal)? • Jumps require absolute address. • What about references to data? •la gets broken up into lui and ori • These will require the full 32-bit address of the data. • These can’t be determined yet, so we create two tables for use by linker/loader… CS 61C L13 CALL (17) A Carle, Summer 2006 © UCB 1: Symbol Table • List of “items” provided by this file. • What are they? - Labels: function calling - Data: anything in the .data section; variables which may be accessed across files • Includes base address of label in the file. CS 61C L13 CALL (18) A Carle, Summer 2006 © UCB 2: Relocation Table • List of “items” needed by this file. • Any label jumped to: j or jal - internal - external (including lib files) • Any named piece of data - Anything referenced by the la instruction - static variables • Contains base address of instruction w/dependency, dependency name CS 61C L13 CALL (19) A Carle, Summer 2006 © UCB Question • Which lines go in the symbol table and/or relocation table? my_func: lui $a0 my_arrayh # a (from la) ori $a0 $a0 my_arrayl # b (from la) jal add_link # c bne $a0,$v0, my_func # d A: Symbol: my_func relocate: my_array B: - relocate: my_array C: - relocate: add_link D: -- CS 61C L13 CALL (20) A Carle, Summer 2006 © UCB Peer Instruction 1 1. Assembler knows where a module’s data & instructions are in relation to other modules. 2. Assembler will ignore the instruction Loop:nop because it does nothing. 3. Java designers used an interpreter (rather than a translater) mainly because of (at least one of): ease of writing, better error msgs, smaller object code. CS 61C L13 CALL (21) A Carle, Summer 2006 © UCB Administrivia • HW 4 • Due Online Friday • Project 2 • Released Today • Due ? • Midterm 2 • Plan for August 4th CS 61C L13 CALL (22) A Carle, Summer 2006 © UCB Object File Format • object file header: size and position of the other pieces of the object file • text segment: the machine code • data segment: binary representation of the data in the source file • relocation information: identifies lines of code that need to be “handled” • symbol table: list of this file’s labels and data that can be referenced • debugging information CS 61C L13 CALL (23) A Carle, Summer 2006 © UCB Where Are We Now? C program: foo.c Compiler Assembly program: foo.s Assembler Object(mach lang module): foo.o Linker lib.o Executable(mach lang pgm): a.out Loader Memory CS 61C L13 CALL (24) A Carle, Summer 2006 © UCB Link Editor/Linker (1/3) • Input: Object Code, information tables (e.g., foo.o for MIPS) • Output: Executable Code (e.g., a.out for MIPS) • Combines several object (.o) files into a single executable (“linking”) • Enable Separate Compilation of files • Changes to one file do not require recompilation of whole program - Windows NT source is >40 M lines of code! • Link Editor name from editing the “links” in jump and link instructions CS 61C L13 CALL (25) A Carle, Summer 2006 © UCB Link Editor/Linker (2/3) .o file 1 text 1 a.out data 1 Relocated text 1 info 1 Linker Relocated text 2 .o file 2 Relocated data 1 text 2 Relocated data 2 data 2 info 2 CS 61C L13 CALL (26) A Carle, Summer 2006 © UCB Link Editor/Linker (3/3) • Step 1: Take text segment from each .o file and put them together. • Step 2: Take data segment from each .o file, put them together, and concatenate this onto end of text segments. • Step 3: Resolve References • Go through Relocation Table and handle each entry • That is, fill in all absolute addresses CS 61C L13 CALL (27) A Carle, Summer 2006 © UCB Resolving References (1/2) • Linker assumes first word of first text segment is at address 0x00000000. • Linker knows: • length of each text and data segment • ordering of text and data segments • Linker calculates: • absolute address of each label to be jumped to (internal or external) and each piece of data being referenced CS 61C L13 CALL (28) A Carle, Summer 2006 © UCB Resolving References (2/2) • To resolve references: • search for reference (data or label) in all symbol tables • if not found, search library files (for example, for printf) • once absolute address is determined, fill in the machine code appropriately • Output of linker: executable file containing text and data (plus header) CS 61C L13 CALL (29) A Carle, Summer 2006 © UCB Where Are We Now? C program: foo.c Compiler Assembly program: foo.s Assembler Object(mach lang module): foo.o Linker lib.o Executable(mach lang pgm): a.out Loader Memory CS 61C L13 CALL (30) A Carle, Summer 2006 © UCB Loader (1/3) • Input: Executable Code (e.g., a.out for MIPS) • Output: (program is run) • Executable files are stored on disk.
Load more

Recommended publications
  • Doin' the Eagle Rock
    VIRUS BULLETIN www.virusbtn.com MALWARE ANALYSIS 1 DOIN’ THE EAGLE ROCK this RNG in every virus for which he requires a source of random numbers. Peter Ferrie Microsoft, USA The virus then allocates two blocks of memory: one to hold the intermediate encoding of the virus body, and the other to hold the fully encoded virus body. The virus decompresses If a fi le contains no code, can it be executed? Can arithmetic a fi le header into the second block. The fi le header is operations be malicious? Here we have a fi le that contains compressed using a simple Run-Length Encoder algorithm. no code, and no data in any meaningful sense. All it The header is for a Windows Portable Executable fi le, and it contains is a block of relocation items, and all relocation seems as though the intention was to produce the smallest items do is cause a value to be added to locations in the possible header that can still be executed on Windows. There image. So, nothing but relocation items – and yet it also are overlapping sections, and ‘unnecessary’ fi elds have been contains W32/Lerock. removed. The virus then allocates a third block of memory, Lerock is written by the same virus author as W32/Fooper which will hold a copy of the unencoded virus body. (see VB, January 2010, p.4), and behaves in the same way at a The virus searches for zeroes within the unencoded memory high level, but at a lower level it differs in an interesting way.
    [Show full text]
  • 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]
  • Tricore Architecture Manual for a Detailed Discussion of Instruction Set Encoding and Semantics
    User’s Manual, v2.3, Feb. 2007 TriCore 32-bit Unified Processor Core Embedded Applications Binary Interface (EABI) Microcontrollers Edition 2007-02 Published by Infineon Technologies AG 81726 München, Germany © Infineon Technologies AG 2007. All Rights Reserved. Legal Disclaimer The information given in this document shall in no event be regarded as a guarantee of conditions or characteristics (“Beschaffenheitsgarantie”). With respect to any examples or hints given herein, any typical values stated herein and/or any information regarding the application of the device, Infineon Technologies hereby disclaims any and all warranties and liabilities of any kind, including without limitation warranties of non- infringement of intellectual property rights of any third party. Information For further information on technology, delivery terms and conditions and prices please contact your nearest Infineon Technologies Office (www.infineon.com). Warnings Due to technical requirements components may contain dangerous substances. For information on the types in question please contact your nearest Infineon Technologies Office. Infineon Technologies Components may only be used in life-support devices or systems with the express written approval of Infineon Technologies, if a failure of such components can reasonably be expected to cause the failure of that life-support device or system, or to affect the safety or effectiveness of that device or system. Life support devices or systems are intended to be implanted in the human body, or to support and/or maintain and sustain and/or protect human life. If they fail, it is reasonable to assume that the health of the user or other persons may be endangered. User’s Manual, v2.3, Feb.
    [Show full text]
  • The 7 Dwarves: Debugging Information Beyond Gdb
    The 7 dwarves: debugging information beyond gdb Arnaldo Carvalho de Melo Red Hat, Inc. [email protected] [email protected] Abstract • To find out possibilities for reduction of such data structures; The DWARF debugging information format has been so • Use of information about function parameters and far used in debuggers such as gdb, and more recently in return types to generate Linux kernel modules for tools such as systemtap and frysk. obtaining data needed for generation of callgraphs In this paper the author will show additional scenarios and values set to fields at runtime; where such information can be useful, such as: • A tool that given two object files shows a binary diff to help understanding the effects of source • Showing the layout of data structures; code changes on size of functions and data struc- tures. • Reorganizing such data structures to remove align- ment holes; Some use cases will be presented, showing how the tools • Improving CPU cache utilization; can be used to solve real world problems. • Displaying statistics about inlining of functions; Ideas discussed with some fellow developers but not yet • Re-creating structs and functions from the debug- tried will also be presented, with the intent of hopefully ging information; having them finally tested in practice by interested read- ers. • Showing binary diffs to help understand the effects of any code change. 2 DWARF Debugging Format And much more. DWARF [3] is a debugging file format used by many compilers to store information about data structures, 1 Introduction variables, functions and other language aspects needed by high level debuggers.
    [Show full text]
  • Linking Basics.Docx Page 1 of 35 Initial Creation: March, 24, 2015 Date Updated: October 4, 2015
    An Overview of Object Files And Linking Harry H. Porter III Portland State University cs.pdx.edu/~harry April 9, 2015 Goals of this Paper Audience: CS-201 students Coverage: Compiling Linking Object files External Symbols Relocatable Code Segments (.text, .data., .bss) Filename: Linking Basics.docx Page 1 of 35 Initial Creation: March, 24, 2015 Date Updated: October 4, 2015 Overview In order to create an executable file, a program must be compiled and linked. In this paper, I’ll use the “C” programming language as an example, but this discussion applies to other compiled languages like C++. Languages that are interpreted (like Java or Python) do things differently and linking does not apply to them. We’ll also discuss the Linux/Unix system, but other OSes are similar. A program begins as a human readable source text file, such as “hello.c”. The program must first be compiled and this step produces a human readable text file in assembly code. Then the assembly code version is assembled and this produces an object file. Finally, the object file is linked and the executable file is produced. At some later time, the OS will load the executable file into memory run it. Many programs are large and these programs are broken into several “.c” files. We’ll look at an example involving two files, “hello.c” and “there.c”. Each of the .c files must be compiled and assembled, but these steps can be done independently. In other words, we can compile and assemble hello.c before we even create the there.c file.
    [Show full text]
  • Chapter 13 ARM Image Format
    Chapter 13 ARM Image Format This chapter describes the ARM Image Format (AIF). It contains the following sections: • Overview of the ARM Image Format on page 13-2 • AIF variants on page 13-3 • The layout of AIF on page 13-4. ARM DUI 0041C Copyright © 1997 and 1998 ARM Limited. All rights reserved. 13-1 ARM Image Format 13.1 Overview of the ARM Image Format ARM Image Format (AIF) is a simple format for ARM executable images, consisting of: • a 128-byte header • the image code • the image initialized static data. An AIF image is capable of self-relocation if it is created with the appropriate linker options. The image can be loaded anywhere and it will execute where it is loaded. After an AIF image has been relocated, it can create its own zero-initialized area. Finally, the image is entered at the unique entry point. 13-2 Copyright © 1997 and 1998 ARM Limited. All rights reserved. ARM DUI 0041C ARM Image Format 13.2 AIF variants There are three variants of AIF: Executable AIF Executable AIF can be loaded at its load address and entered at the same point (at the first word of the AIF header). It prepares itself for execution by relocating itself if required and setting to zero its own zero-initialized data. The header is part of the image itself. Code in the header ensures that the image is properly prepared for execution before being entered at its entry address. The fourth word of an executable AIF header is: BL entrypoint The most significant byte of this word (in the target byte order) is 0xeb.
    [Show full text]
  • Symbol Table Relocation Table Object File Format Where Are We Now
    inst.eecs.berkeley.edu/~cs61c UCB CS61C : Machine Structures Symbol Table Lecture 19 – Running a Program II . List of “items” in this file that may be used by other files. (Compiling, Assembling, Linking, Loading) Hello to . What are they? Lecturer SOE 2008-03-05 Neil Sharma Labels: function calling Dan Garcia from the 3rd row! Data: anything in the .data section; variables which may be accessed across files Researchers at Princeton have developed a flexible electricity-producing sheet of rubber that can use body movements into electricity. Breathing generates 1 W, walking around the room generates 70 W. Shoes may be the best place, to power/recharge cell phones & iPods. www.nytimes.com/2010/03/02/science/02obribbon.html CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (3) Garcia, Spring 2010 © UCB Relocation Table Object File Format . List of “items” this file needs the address later. object file header: size and position of the other . What are they? pieces of the object file Any label jumped to: j or jal . text segment: the machine code internal . data segment: binary representation of the data in external (including lib files) the source file Any piece of data connected with an address . relocation information: identifies lines of code that such as the la instruction need to be “handled” . symbol table: list of this file’s labels and data that can be referenced . debugging information . A standard format is ELF (except MS) http://www.skyfree.org/linux/references/ELF_Format.pdf CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (4) Garcia, Spring 2010 © UCB CS61C L19 : Running a Progam II … Compiling, Assembling, Linking, and Loading (5) Garcia, Spring 2010 © UCB Where Are We Now? Linker (1/3) .
    [Show full text]
  • Introduction to Computer Systems 15-213/18-243, Spring 2009
    Carnegie Mellon Linking 15-213: Introduction to Computer Systems 13th Lecture, February 23rd, 2016 Instructors: Franz Franchetti & Seth Copen Goldstein, Ralf Brown, and Brian Railing Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 1 Carnegie Mellon Today Linking Case study: Library interpositioning Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 2 Carnegie Mellon Example C Program int sum(int *a, int n); int sum(int *a, int n) { int array[2] = {1, 2}; int i, s = 0; int main() for (i = 0; i < n; i++) { { s += a[i]; int val = sum(array, 2); } return val; return s; } } main.c sum.c Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 3 Carnegie Mellon Static Linking Programs are translated and linked using a compiler driver: . linux> gcc -Og -o prog main.c sum.c . linux> ./prog main.c sum.c Source files Translators Translators (cpp, cc1, as) (cpp, cc1, as) main.o sum.o Separately compiled relocatable object files Linker (ld) Fully linked executable object file prog (contains code and data for all functions defined in main.c and sum.c) Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 4 Carnegie Mellon Why Linkers? Reason 1: Modularity . Program can be written as a collection of smaller source files, rather than one monolithic mass. Can build libraries of common functions (more on this later) . e.g., Math library, standard C library Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 5 Carnegie Mellon Why Linkers? (cont) Reason 2: Efficiency .
    [Show full text]
  • 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]
  • Codewarrior Development Studio for Starcore 3900FP Dsps Application Binary Interface (ABI) Reference Manual
    CodeWarrior Development Studio for StarCore 3900FP DSPs Application Binary Interface (ABI) Reference Manual Document Number: CWSCABIREF Rev. 10.9.0, 06/2015 CodeWarrior Development Studio for StarCore 3900FP DSPs Application Binary Interface (ABI) Reference Manual, Rev. 10.9.0, 06/2015 2 Freescale Semiconductor, Inc. Contents Section number Title Page Chapter 1 Introduction 1.1 Standards Covered............................................................................................................................................................ 7 1.2 Accompanying Documentation........................................................................................................................................ 8 1.3 Conventions...................................................................................................................................................................... 8 1.3.1 Numbering Systems............................................................................................................................................. 8 1.3.2 Typographic Notation.......................................................................................................................................... 9 1.3.3 Special Terms.......................................................................................................................................................9 Chapter 2 Low-level Binary Interface 2.1 StarCore Architectures......................................................................................................................................................11
    [Show full text]
  • An Evil Copy: How the Loader Betrays You
    An Evil Copy: How the Loader Betrays You Xinyang Ge Mathias Payer Trent Jaeger Microsoft Research Purdue University The Pennsylvania State University [email protected] [email protected] [email protected] Abstract—Dynamic loading is a core feature used on current the value that is being written. Despite significant investment in systems to (i) enable modularity and reuse, (ii) reduce memory bug finding techniques, memory corruption is still an important footprint by sharing code pages of libraries and executables problem, as 745 individual CVEs for 2015 and 692 CVEs for among processes, and (iii) simplify update procedures by elim- 2016 are reported. While not all these vulnerabilities allow an inating the need to recompile executables when a library is attacker to compromise a system with arbitrary code execution, updated. The Executable and Linkable Format (ELF) is a generic many do. specification that describes how executable programs are stitched together from object files produced from source code to libraries Without any defense, attackers inject and execute code to and executables. Programming languages allow fine-grained con- trol over variables, including access and memory protections, so take control of a system through memory corruption vulner- programmers may write defense mechanisms assuming that the abilities. Over the past decade, a set of defense mechanisms permissions specified at the source and/or compiler level will hold have been deployed on commodity systems. Data execution at runtime. prevention [5] is a common defense that enforces code in- tegrity. Code integrity prohibits an attacker from injecting new Unfortunately, information about memory protection is lost code into a running process and is usually enforced by hard- during compilation.
    [Show full text]
  • Kitty Reeves MTWR 10:20-12:25Pm
    Summer 2013 CSE2421 Systems1 Introduction to Low-Level Programming and Computer Organization Kitty Reeves MTWR 10:20-12:25pm 1 Compiler Drivers = GCC When you invoke GCC, it normally does preprocessing, compilation, assembly and linking, as needed, on behalf of the user accepts options and file names as operands % gcc –O1 -g -o prog main.c swap.c % man gcc Pre-processor (cpp) .c to .i Compiler (cc1) .i file to .s Compiler Assembler (as) .s to “relocatable” object file .o driver Linker (ld) creates executable object file called a.out as default Loader the unix shell invokes a function in the OS to call the loader Copies the code and data in the executable file into memory Transfers control to the beginning of the program Remember the flow chart of this info that we’ve seen multiple times already? 2 Overview example 3 Compiling, linking… What happens when you use the compiler driver? gcc -O2 -g -o test main.c swap.c Step1 – Preprocessor (cpp) The C preprocessor translates the C source file main.c into an ASCII intermediate file main.i cpp [other args] main.c /tmp/main.i Step2 – C compiler (ccl) Driver runs C compiler cc1 translates main.i into an ASCII assembly language file main.s cc1 /tmp/main.i main.c -O2 [other args] -o /tmp/main.s 4 Compiling, Linking… (cont) Step3 – Assembler (as) driver runs assembler as to translate main.s into relocatable object file main.o as [other args] -o /tmp/main.o /tmp/main.s Same 3 steps are executed for swap.c Step4 – Linker (ld) driver runs linker ld to combine main.o and swap.o into the executable
    [Show full text]