DOCSLIB.ORG

Linking Today Example C Program Stapc Linking

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Carnegie Mellon Carnegie Mellon Today ¢ Linking Linking ¢ Case study: Library interposioning 15-213 / 18-213: Introduc2on to Computer Systems 12th Lecture, Feb. 23, 2012 Instructors: Todd C. Mowry & Anthony Rowe 1 2 Carnegie Mellon Carnegie Mellon Example C Program Sta7c Linking ¢ Programs are translated and linked using a compiler driver: main.c swap.c § unix> gcc -O2 -g -o p main.c swap.c int buf[2] = {1, 2}; extern int buf[]; § unix> ./p int main() int *bufp0 = &buf[0]; { static int *bufp1; main.c swap.c Source files swap(); return 0; void swap() Translators Translators } { (cpp, cc1, as) (cpp, cc1, as) int temp; Separately compiled bufp1 = &buf[1]; main.o swap.o relocatable object files temp = *bufp0; *bufp0 = *bufp1; Linker (ld) *bufp1 = temp; } Fully linked executable object file p (contains code and data for all func;ons defined in main.c and swap.c) 3 4 1 Carnegie Mellon Carnegie Mellon Why Linkers? Why Linkers? (cont) ¢ Reason 1: Modularity ¢ Reason 2: Efficiency § Program can be wriKen as a coLLec2on of smalLer source fiLes, § Time: Separate compiLaon rather than one monoLithic mass. § Change one source fiLe, compiLe, and then relink. § No need to recompiLe other source fiLes. § Can buiLd Libraries of common func2ons (more on this Later) § e.g., Math Library, standard C Library § Space: Libraries § Common func2ons can be aggregated into a singLe fiLe... § Yet executabLe fiLes and running memory images contain onLy code for the func2ons they actualLy use. 5 6 Carnegie Mellon Carnegie Mellon What Do Linkers Do? What Do Linkers Do? (cont) ¢ Step 1. Symbol resoluon ¢ Step 2. Reloca7on § Programs define and reference symbols (variabLes and func2ons): § Merges separate code and data sec2ons into singLe sec2ons § void swap() {…} /* define symbol swap */ § swap(); /* reference symbol a */ § ReLocates symboLs from their reLave Locaons in the .o fiLes to § int *xp = &x; /* define symbol xp, reference x */ their final absoLute memory Locaons in the executabLe. § SymboL defini2ons are stored (by compiLer) in symbol table. § Updates alL references to these symboLs to reflect their new § SymboL tabLe is an array of structs posions. § Each entry incLudes name, size, and Locaon of symboL. § Linker associates each symboL reference with exactly one symboL defini2on. 7 8 2 Carnegie Mellon Carnegie Mellon Three Kinds of Object Files (Modules) Executable and Linkable Format (ELF) ¢ Relocatable object file (.o file) ¢ Standard binary format for object files § Contains code and data in a form that can be combined with other ¢ Originally proposed by AT&T System V Unix reLocatabLe object fiLes to form executabLe object fiLe. § Later adopted by BSD Unix variants and Linux § Each .o fiLe is produced from exactly one source (.c) file ¢ One unified format for § ReLocatabLe object fiLes (.o), ¢ Executable object file (a.out file) § ExecutabLe object fiLes (a.out) § Contains code and data in a form that can be copied directly into § Shared object fiLes (.so) memory and then executed. ¢ Generic name: ELF binaries ¢ Shared object file (.so file) § Special type of reLocatabLe object fiLe that can be Loaded into memory and Linked dynamicalLy, at either Load 2me or run-2me. § CalLed Dynamic Link Libraries (DLLs) by Windows 9 10 Carnegie Mellon Carnegie Mellon ELF Object File Format ELF Object File Format (cont.) ¢ Elf header § Word size, byte ordering, fiLe type (.o, ¢ .symtab secon 0 0 exec, .so), machine type, etc. ELF header § SymboL tabLe ELF header § Procedure and stac variabLe names ¢ Segment header table Segment header table Segment header table § Sec2on names and Locaons § Page size, virtual addresses memory segments (required for executables) (required for executables) (sec2ons), segment sizes. .text secon ¢ .rel.text secon .text secon § ReLocaon info for .text secon ¢ .text secon .rodata secon § Addresses of instruc2ons that wiLL need to be .rodata secon § Code .data secon modified in the executabLe .data secon § Instruc2ons for modifying. ¢ .rodata sec7on .bss secon .bss secon § Read onLy data: jump tabLes, ... ¢ .rel.data secon .symtab sec7on § ReLocaon info for .data secon .symtab sec7on ¢ .data secon .rel.txt sec7on § Addresses of pointer data that wiLL need to be .rel.txt sec7on § Ini2alized gLobal variabLes modified in the merged executabLe .rel.data sec7on .rel.data sec7on ¢ .bss secon ¢ .debug secon .debug sec7on .debug sec7on § Unini2alized gLobal variabLes § Info for symboLic debugging (gcc -g) § “BLock Started by SymboL” Sec7on header table ¢ Sec7on header table Sec7on header table § “BeKer Save Space” § Offsets and sizes of each sec2on § Has sec2on header but occupies no space 11 12 3 Carnegie Mellon Carnegie Mellon Linker Symbols Resolving Symbols Global External Local ¢ Global symbols Global § Symbols defined by module m that can be referenced by other moduLes. int buf[2] = {1, 2}; extern int buf[]; § E.g.: non-static C func2ons and non-static gLobal variabLes. int main() int *bufp0 = &buf[0]; { static int *bufp1; ¢ External symbols swap(); § GLobal symboLs that are referenced by moduLe m but defined by some return 0; void swap() Global other moduLe. } main.c { int temp; ¢ Local symbols External Linker knows bufp1 = &buf[1]; § SymboLs that are defined and referenced excLusiveLy by moduLe m. nothing of temp temp = *bufp0; § E.g.: C func2ons and variabLes defined with the static aribute. *bufp0 = *bufp1; *bufp1 = temp; § Local linker symbols are not local program variables } swap.c 13 14 Carnegie Mellon Carnegie Mellon Reloca7ng Code and Data Reloca7on Info (main) Relocatable Object Files Executable Object File main.c main.o int buf[2] = 0000000 <main>: {1,2}; 0: 8d 4c 24 04 lea 0x4(%esp),%ecx 4: 83 e4 f0 and $0xfffffff0,%esp System code .text 0 Headers int main() 7: ff 71 fc pushl 0xfffffffc(%ecx) a: 55 push %ebp System data .data System code { b: 89 e5 mov %esp,%ebp swap(); d: 51 push %ecx main() return 0; e: 83 ec 04 sub $0x4,%esp .text main.o } 11: e8 fc ff ff ff call 12 <main+0x12> swap() 12: R_386_PC32 swap main() .text 16: 83 c4 04 add $0x4,%esp More system code 19: 31 c0 xor %eax,%eax int buf[2]={1,2} .data 1b: 59 pop %ecx System data 1c: 5d pop %ebp swap.o int buf[2]={1,2} .data 1d: 8d 61 fc lea 0xfffffffc(%ecx),%esp int *bufp0=&buf[0] 20: c3 ret swap() .text int *bufp1 .bss int *bufp0=&buf[0] .data .symtab .debug Disassembly of section .data: static int *bufp1 .bss Source: objdump –r -d 00000000 <buf>: Even though private to swap, requires allocaon in .bss 0: 01 00 00 00 02 00 00 00 15 16 4 Carnegie Mellon Carnegie Mellon Reloca7on Info (swap, .text) Reloca7on Info (swap, .data) swap.c swap.o swap.c extern int buf[]; Disassembly of section .text: Disassembly of section .data: extern int buf[]; 00000000 <swap>: int 00000000 <bufp0>: *bufp0 = &buf[0]; 0: 8b 15 00 00 00 00 mov 0x0,%edx int *bufp0 = 2: R_386_32 buf &buf[0]; 0: 00 00 00 00 6: a1 04 00 00 00 mov 0x4,%eax static int *bufp1; static int *bufp1; 7: R_386_32 buf 0: R_386_32 buf b: 55 push %ebp void swap() c: 89 e5 mov %esp,%ebp void swap() { e: c7 05 00 00 00 00 04 movl $0x4,0x0 { int temp; 15: 00 00 00 int temp; 10: R_386_32 .bss bufp1 = &buf[1]; 14: R_386_32 buf bufp1 = &buf[1]; 18: 8b 08 mov (%eax),%ecx temp = *bufp0; temp = *bufp0; 1a: 89 10 mov %edx,(%eax) *bufp0 = *bufp1; *bufp0 = *bufp1; 1c: 5d pop %ebp *bufp1 = temp; *bufp1 = temp; 1d: 89 0d 04 00 00 00 mov %ecx,0x4 } 1f: R_386_32 buf } 23: c3 ret 17 18 Carnegie Mellon Carnegie Mellon 0: 8b 15 00 00 00 00 mov 0x0,%edx Executable Before/Aer Reloca7on (.text) 2: R_386_32 buf 0000000 <main>: 6: a1 04 00 00 00 mov 0x4,%eax . 0x8048396 + 0x1a 7: R_386_32 buf e: 83 ec 04 sub $0x4,%esp ... 11: e8 fc ff ff ff call 12 <main+0x12> = 0x80483b0 e: c7 05 00 00 00 00 04 movl $0x4,0x0 12: R_386_PC32 swap 15: 00 00 00 16: 83 c4 04 add $0x4,%esp 10: R_386_32 .bss . 14: R_386_32 buf . 08048380 <main>: 1d: 89 0d 04 00 00 00 mov %ecx,0x4 8048380: 8d 4c 24 04 lea 0x4(%esp),%ecx 1f: R_386_32 buf 8048384: 83 e4 f0 and $0xfffffff0,%esp 23: c3 ret 8048387: ff 71 fc pushl 0xfffffffc(%ecx) 804838a: 55 push %ebp 080483b0 <swap>: 804838b: 89 e5 mov %esp,%ebp 80483b0: 8b 15 20 96 04 08 mov 0x8049620,%edx 804838d: 51 push %ecx 80483b6: a1 24 96 04 08 mov 0x8049624,%eax 804838e: 83 ec 04 sub $0x4,%esp 80483bb: 55 push %ebp 8048391: e8 1a 00 00 00 call 80483b0 <swap> 80483bc: 89 e5 mov %esp,%ebp 8048396: 83 c4 04 add $0x4,%esp 80483be: c7 05 30 96 04 08 24 movl $0x8049624,0x8049630 8048399: 31 c0 xor %eax,%eax 80483c5: 96 04 08 804839b: 59 pop %ecx 80483c8: 8b 08 mov (%eax),%ecx 804839c: 5d pop %ebp 80483ca: 89 10 mov %edx,(%eax) 804839d: 8d 61 fc lea 0xfffffffc(%ecx),%esp 80483cc: 5d pop %ebp 80483a0: c3 ret 80483cd: 89 0d 24 96 04 08 mov %ecx,0x8049624 80483d3: c3 ret 19 20 5 Carnegie Mellon Carnegie Mellon Executable Aer Reloca7on (.data) Strong and Weak Symbols ¢ Program symbols are either strong or weak Disassembly of section .data: § Strong: procedures and ini2alized gLobals 08049620 <buf>: § Weak: unini2alized gLobals 8049620: 01 00 00 00 02 00 00 00 08049628 <bufp0>: 8049628: 20 96 04 08 p1.c p2.c strong int foo=5; int foo; weak strong p1() { p2() { strong } } 21 22 Carnegie Mellon Carnegie Mellon Linker’s Symbol Rules Linker Puzzles int x; Link 2me error: two strong symboLs (p1) ¢ Rule 1: Mul7ple strong symbols are not allowed p1() {} p1() {} § Each item can be defined onLy once § Otherwise: Linker error int x; int x; References to x wiLL refer to the same p1() {} p2() {} unini2alized int.
Recommended publications
  • The “Stabs” Debug Format

    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
  • Portable Executable File Format

    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.
  • Architectural Support for Dynamic Linking Varun Agrawal, Abhiroop Dabral, Tapti Palit, Yongming Shen, Michael Ferdman COMPAS Stony Brook University

    Architectural Support for Dynamic Linking Varun Agrawal, Abhiroop Dabral, Tapti Palit, Yongming Shen, Michael Ferdman COMPAS Stony Brook University

    Architectural Support for Dynamic Linking Varun Agrawal, Abhiroop Dabral, Tapti Palit, Yongming Shen, Michael Ferdman COMPAS Stony Brook University Abstract 1 Introduction All software in use today relies on libraries, including All computer programs in use today rely on software standard libraries (e.g., C, C++) and application-specific libraries. Libraries can be linked dynamically, deferring libraries (e.g., libxml, libpng). Most libraries are loaded in much of the linking process to the launch of the program. memory and dynamically linked when programs are Dynamically linked libraries offer numerous benefits over launched, resolving symbol addresses across the applica- static linking: they allow code reuse between applications, tions and libraries. Dynamic linking has many benefits: It conserve memory (because only one copy of a library is kept allows code to be reused between applications, conserves in memory for all applications that share it), allow libraries memory (because only one copy of a library is kept in mem- to be patched and updated without modifying programs, ory for all the applications that share it), and allows enable effective address space layout randomization for libraries to be patched and updated without modifying pro- security [21], and many others. As a result, dynamic linking grams, among numerous other benefits. However, these is the predominant choice in all systems today [7]. benefits come at the cost of performance. For every call To facilitate dynamic linking of libraries, compiled pro- made to a function in a dynamically linked library, a trampo- grams include function call trampolines in their binaries. line is used to read the function address from a lookup table When a program is launched, the dynamic linker maps the and branch to the function, incurring memory load and libraries into the process address space and resolves external branch operations.
  • Common Object File Format (COFF)

    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
  • CS429: Computer Organization and Architecture Linking I & II

    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.
  • Chapter 6: the Linker

    Chapter 6: the Linker

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

    Protecting Against Unexpected System Calls

    Protecting Against Unexpected System Calls C. M. Linn, M. Rajagopalan, S. Baker, C. Collberg, S. K. Debray, J. H. Hartman Department of Computer Science University of Arizona Tucson, AZ 85721 {linnc,mohan,bakers,collberg,debray,jhh}@cs.arizona.edu Abstract writing the return address on the stack with the address of the attack code). This then causes the various actions This paper proposes a comprehensive set of techniques relating to the attack to be carried out. which limit the scope of remote code injection attacks. These techniques prevent any injected code from mak- In order to do any real damage, e.g., create a root ing system calls and thus restrict the capabilities of an shell, change permissions on a file, or access proscribed attacker. In defending against the traditional ways of data, the attack code needs to execute one or more sys- harming a system these techniques significantly raise the tem calls. Because of this, and the well-defined system bar for compromising the host system forcing the attack call interface between application code and the underly- code to take extraordinary steps that may be impractical ing operating system kernel, many researchers have fo- in the context of a remote code injection attack. There cused on the system call interface as a convenient point are two main aspects to our approach. The first is to for detecting and disrupting such attacks (see, for exam- embed semantic information into executables identify- ple, [5, 13, 17, 19, 29, 32, 35, 38]; Section 7 gives a more ing the locations of legitimate system call instructions; extensive discussion).
  • Cray XT Programming Environment's Implementation of Dynamic Shared Libraries

    Cray XT Programming Environment's Implementation of Dynamic Shared Libraries

    Cray XT Programming Environment’s Implementation of Dynamic Shared Libraries Geir Johansen, Cray Inc. Barb Mauzy, Cray Inc. ABSTRACT: The Cray XT Programming Environment will support the implementation of dynamic shared libraries in future Cray XT CLE releases. The Cray XT implementation will provide the flexibility to allow specific library versions to be chosen at both link and run times. The implementation of dynamic shared libraries allows dynamically linked executables built with software other than the Cray Programming Environment to be run on the Cray XT. KEYWORDS: Cray XT, Programming Environment CUG 2009 Proceedings 1 of 10 information in physical memory that can be shared among 1.0 Introduction multiple processes. This feature potentially reduces the memory allocated for a program on a compute node. This The goal of this paper is provide application analysts advantage becomes more important as the number of a description of Cray XT Programming Environment‟s available cores increases. implementation of dynamic shared libraries. Topics Another advantage of dynamically linked executables covered include the building of dynamic shared library is that the system libraries can be upgraded and take effect programs, configuring the version of dynamic shared without the need to relink applications. The ability to libraries to be used at execution time, and the execution of install library changes without having to rebuild a program a dynamically linked program not built with the Cray XT is a significant advantage in quickly addressing problems, Programming Environment. While a brief description of such as a security issue with a library code. The the Cray XT system implementation of dynamic shared experiences of system administrators have shown that libraries will be given, the Cray XT system architecture codes using dynamic shared libraries are more resilient to and system administration issues of dynamic shared system upgrades than codes using static libraries [1].
  • Dynamic Linking Considered Harmful

    Dynamic Linking Considered Harmful

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

    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.
  • Linker Script Guide Emprog

    Linker Script Guide Emprog

    Linker Script Guide Emprog Emprog ThunderBench™ Linker Script Guide Version 1.2 ©May 2013 Page | 1 Linker Script Guide Emprog 1 - Linker Script guide 2 -Arm Specific Options Page | 2 Linker Script Guide Emprog 1 The Linker Scripts Every link is controlled by a linker script. This script is written in the linker command language. The main purpose of the linker script is to describe how the sections in the input files should be mapped into the output file, and to control the memory layout of the output file. Most linker scripts do nothing more than this. However, when necessary, the linker script can also direct the linker to perform many other operations, using the commands described below. The linker always uses a linker script. If you do not supply one yourself, the linker will use a default script that is compiled into the linker executable. You can use the ‘--verbose’ command line option to display the default linker script. Certain command line options, such as ‘-r’ or ‘-N’, will affect the default linker script. You may supply your own linker script by using the ‘-T’ command line option. When you do this, your linker script will replace the default linker script. You may also use linker scripts implicitly by naming them as input files to the linker, as though they were files to be linked. 1.1 Basic Linker Script Concepts We need to define some basic concepts and vocabulary in order to describe the linker script language. The linker combines input files into a single output file. The output file and each input file are in a special data format known as an object file format.
  • Chapter 13 ARM Image Format

    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.