DOCSLIB.ORG

64-Bit Powerpc ELF Application Binary Interface Supplement 1.7

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
64-Bit Powerpc ELF Application Binary Interface Supplement 1.7 64-bit PowerPC ELF Application Binary Interface Supplement 1.7 Ian Lance Taylor Zembu Labs 64-bit PowerPC ELF Application Binary Interface Supplement 1.7 by Ian Lance Taylor 1.7 Edition Published Sep 15, 2003 Copyright © 1999, 2004 IBM Corporation Copyright © 2003, 2004 Free Standards Group Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is available from http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/gfdl.html. The following terms are trademarks or registered trademarks of International Business Machines Corporation in the United States and/or other countires: AIX, PowerPC. A full list U.S. trademarks owned by IBM may be found at http://www.ibm.com/legal/copytrade.shtml. Revision History Revision 1.1 Revised by: David Edelsohn, IBM Research Revision 1.2 Revised by: Torbjorn Granlund, Swox AB Revision 1.3 Revised by: David Edelsohn and Mark Mendell, IBM Revision 1.4 Revised by: Alan Modra, IBM Revision 1.4.1 Revised by: Kristin Thomas, IBM Revision 1.5 Revised by: Alan Modra, IBM Revision 1.6 Revised by: Alan Modra, IBM Revision 1.7 Revised by: Alan Modra, David Edelsohn and Steven Munroe, IBM Table of Contents 1. Introduction........................................................................................................................................................1 1.1. How to Use the 64-bit PowerPC ELF ABI Supplement .........................................................................1 2. Software Installation..........................................................................................................................................2 2.1. Physical Distribution Media and Formats ...............................................................................................2 3. Low Level System Information.........................................................................................................................3 3.1. Machine Interface....................................................................................................................................3 3.1.1. Processor Architecture................................................................................................................3 3.1.2. Data Representation....................................................................................................................3 3.1.3. Byte Ordering .............................................................................................................................3 3.1.4. Fundamental Types.....................................................................................................................5 3.1.5. Extended Precision .....................................................................................................................6 3.1.6. Aggregates and Unions...............................................................................................................6 3.1.7. Bit-fields .....................................................................................................................................9 3.2. Function Calling Sequence....................................................................................................................14 3.2.1. Registers ...................................................................................................................................15 3.2.2. The Stack Frame.......................................................................................................................16 3.2.3. Parameter Passing.....................................................................................................................18 3.2.4. Return Values............................................................................................................................21 3.2.5. Function Descriptors.................................................................................................................21 3.3. Traceback Tables ...................................................................................................................................22 3.3.1. Mandatory Fields......................................................................................................................22 3.3.2. Optional Fields..........................................................................................................................24 3.4. Process Initialization .............................................................................................................................26 3.4.1. Registers ...................................................................................................................................26 3.4.2. Process Stack ............................................................................................................................27 3.5. Coding Examples ..................................................................................................................................29 3.5.1. Code Model Overview..............................................................................................................30 3.5.2. The TOC section.......................................................................................................................30 3.5.3. TOC Assembly Language Syntax ............................................................................................31 3.5.4. Function Prologue and Epilogue ..............................................................................................33 3.5.5. Register Saving and Restoring Functions.................................................................................33 3.5.6. Saving General Registers Only.................................................................................................34 3.5.7. Saving General Registers and Floating Point Registers ...........................................................34 3.5.8. Saving Floating Point Registers Only.......................................................................................35 3.5.9. Save and Restore Services ........................................................................................................35 3.5.10. Data Objects............................................................................................................................39 3.5.11. Function Calls.........................................................................................................................41 3.5.12. Branching................................................................................................................................43 3.5.13. Dynamic Stack Space Allocation ...........................................................................................44 3.6. DWARF Definition................................................................................................................................46 3.6.1. DWARF Release Number.........................................................................................................46 3.6.2. DWARF Register Number Mapping.........................................................................................46 4. Object Files.......................................................................................................................................................50 4.1. ELF Header ...........................................................................................................................................50 4.2. Special Sections.....................................................................................................................................50 4.3. TOC.......................................................................................................................................................51 4.4. Symbol Table.........................................................................................................................................52 4.4.1. Symbol Values ..........................................................................................................................52 4.5. Relocation..............................................................................................................................................52 iii 4.5.1. Relocation Types.......................................................................................................................52 5. Program Loading and Dynamic Linking.......................................................................................................61 5.1. Program Loading...................................................................................................................................61 5.1.1. Program Interpreter...................................................................................................................63 5.2. Dynamic Linking...................................................................................................................................63 5.2.1. Dynamic Section.......................................................................................................................63 5.2.2. Global Offset Table...................................................................................................................64 5.2.3. Function Addresses...................................................................................................................64
Load more

Recommended publications
  • Data Representation
    Chapter 4 – Data Representation The focus of this chapter is the representation of data in a digital computer. We begin with a review of several number systems (decimal, binary, octal, and hexadecimal) and a discussion of methods for conversion between the systems. The two most important methods are conversion from decimal to binary and binary to decimal. The conversions between binary and each of octal and hexadecimal are quite simple. Other conversions, such as hexadecimal to decimal, are often best done via binary. After discussion of conversion between bases, we discuss the methods used to store integers in a digital computer: one’s complement and two’s complement arithmetic. This includes a characterization of the range of integers that can be stored given the number of bits allocated to store an integer. The most common integer storage formats are 16, 32, and 64 bits. The next topic for this chapter is the storage of real (floating point) numbers. This discussion will mention the standard put forward by the Institute of Electrical and Electronic Engineers, the IEEE Standard 754 for floating point numbers, but will focus on the base–16 format used by IBM Mainframes. The chapter closes with a discussion of codes for storing characters, focusing on the EBCDIC system used on IBM mainframes. Number Systems There are four number systems of possible interest to the computer programmer: decimal, binary, octal, and hexadecimal. Each system is characterized by its base or radix, always given in decimal, and the set of permissible digits. Note that the hexadecimal numbering system calls for more than ten digits, so we use the first six letters of the alphabet.
    [Show full text]
  • 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]
  • Bits and Bytes and Words, Oh My!
    Bits and Bytes and Words, Oh My! Let’s get down to the real ni8y gri8y • CIS 211 In principle you already know ... Computer memory is binary (base 2) Everything: instrucEons, numbers, strings, ... memory is just one big array of binary numbers If I ask you what 01101011101010 represents, the only correct answer is “it depends” 0 = False = 0 volts; 1 = True = 5 volts (maybe) • CIS 211 CPU and Memory Main Memory CPU Address ALU Reg Reg Reg Values Reg Reg Reg Reg Reg Reg Other buses • CIS 211 CPU and Memory (simplified*) Main Memory CPU Address ALU Reg Reg Reg Values Reg Reg Reg Reg Reg Reg Other buses • CIS 211 (*with several useful lies) CPU and Memory CPU places a memory address on the address bus CPU may place a value on the data base and assert a “write” line (wire) or assert a “read” line and read a value from the data bus Main Memory CPU Address ALU Reg Reg Reg Values Reg Reg Reg Reg Reg Reg Other buses • CIS 211 A few terms: • A bit is a single binary digit • A byte is 8 binary digits • Most computer memory is “byte addressed”; a byte is the smallest addressable unit • What’s half a byte? (4 bits)? • A “word” is a sequence of bytes • Usually 4 bytes (32 bits) or 8 bytes (64 bits) depending on the computer (see next slide) 1 = True = 5 volts ; 0 = False = 0 volts (or 3.3 volts) • CIS 211 Typical byte-addressed memory 15 0 1 0 1 0 0 0 1 with 32-bit words 14 0 0 1 0 0 1 0 0 13 1 1 0 0 1 1 1 0 12 0 0 0 1 1 0 0 0 11 0 1 0 0 1 1 0 0 10 0 0 0 0 0 0 0 0 9 0 0 0 1 1 0 0 0 8 0 0 0 0 0 1 1 0 7 0 0 0 0 0 0 0 0 6 0 0 1 1 1 0 0 1 5 0 1 1 0 0 1 1
    [Show full text]
  • Endian: from the Ground up a Coordinated Approach
    WHITEPAPER Endian: From the Ground Up A Coordinated Approach By Kevin Johnston Senior Staff Engineer, Verilab July 2008 © 2008 Verilab, Inc. 7320 N MOPAC Expressway | Suite 203 | Austin, TX 78731-2309 | 512.372.8367 | www.verilab.com WHITEPAPER INTRODUCTION WHat DOES ENDIAN MEAN? Data in Imagine XYZ Corp finally receives first silicon for the main Endian relates the significance order of symbols to the computers chip for its new camera phone. All initial testing proceeds position order of symbols in any representation of any flawlessly until they try an image capture. The display is kind of data, if significance is position-dependent in that regularly completely garbled. representation. undergoes Of course there are many possible causes, and the debug Let’s take a specific type of data, and a specific form of dozens if not team analyzes code traces, packet traces, memory dumps. representation that possesses position-dependent signifi- There is no problem with the code. There is no problem cance: A digit sequence representing a numeric value, like hundreds of with data transport. The problem is eventually tracked “5896”. Each digit position has significance relative to all down to the data format. other digit positions. transformations The development team ran many, many pre-silicon simula- I’m using the word “digit” in the generalized sense of an between tions of the system to check datapath integrity, bandwidth, arbitrary radix, not necessarily decimal. Decimal and a few producer and error correction. The verification effort checked that all other specific radixes happen to be particularly useful for the data submitted at the camera port eventually emerged illustration simply due to their familiarity, but all of the consumer.
    [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]
  • Binary Numbers 8'S Colum 8'S Colum 2'S Colum 1'S 4'S Colum 4'S N N N N
    Codes and number systems Introduction to Computer Yung-Yu Chuang with slides by Nisan & Schocken (www.nand2tetris.org) and Harris & Harris (DDCA) Coding • Assume that you want to communicate with your friend with a flashlight in a night, what will you do? light painting? What’s the problem? Solution #1 • A: 1 blink • B: 2 blibliknks • C: 3 blinks : • Z: 26 blinks Wha t’s the problem ? • How are you? = 131 blinks Solution #2: Morse code Hello Lookup • It is easy to translate into Morse code than reverse. Why? Lookup Lookup Useful for checking the correctness/ redddundency Braille Braille What’s common in these codes? • They are both binary codes. Binary representations • Electronic Implementation – Easy to store with bitblbistable elemen ts – Reliably transmitted on noisy and inaccurate wires 0 1 0 3.3V 2.8V 0.5V 0.0V Number systems <13> 1 Chapter = = Systems 2 1's column 10 1's column 10's column 2's column 100's column 4's column 1000's column 8's column 5374 1101 Number • numbers Decimal • Binary numbers Number Systems • Decimal numbers 1000's col 10's colum 1's column 100's colu u m n mn n 3 2 1 0 537410 = 5 ? 10 + 3 ? 10 + 7 ? 10 + 4 ? 10 five three seven four thousands hundreds tens ones • Binary numbers 8's colum 2's colum 1's colum 4's colum n n n n 3 2 1 0 11012 = 1 ? 2 + 1 ? 2 + 0 ? 2 + 1 ? 2 = 1310 one one no one eight four two one Chapter 1 <14> Binary numbers • Digits are 1 and 0 (a binary dig it is calle d a bit) 1 = true 0 = false • MSB –most significant bit • LSB –least significant bit MSB LSB • Bit numbering: 1 0 1 1 0
    [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]
  • TCG ACPI Specification
    TCG ACPI Specification Family “1.2” and “2.0” Version 1.3 Revision 8 August 5, 2021 PUBLISHED Contact: [email protected] TCG PUBLISHED Copyright © TCG 2021 TCG TCG ACPI Specification Disclaimers, Notices, and License Terms THIS SPECIFICATION IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Without limitation, TCG disclaims all liability, including liability for infringement of any proprietary rights, relating to use of information in this specification and to the implementation of this specification, and TCG disclaims all liability for cost of procurement of substitute goods or services, lost profits, loss of use, loss of data or any incidental, consequential, direct, indirect, or special damages, whether under contract, tort, warranty or otherwise, arising in any way out of use or reliance upon this specification or any information herein. This document is copyrighted by Trusted Computing Group (TCG), and no license, express or implied, is granted herein other than as follows: You may not copy or reproduce the document or distribute it to others without written permission from TCG, except that you may freely do so for the purposes of (a) examining or implementing TCG specifications or (b) developing, testing, or promoting information technology standards and best practices, so long as you distribute the document with these disclaimers, notices, and license terms. Contact the Trusted Computing Group at www.trustedcomputinggroup.org for information on specification licensing through membership agreements. Any marks and brands contained herein are the property of their respective owners.
    [Show full text]
  • Numbering Systems
    12 Digital Principles Switching Theory R HAPTE 1 C NUMBERING SYSTEMS 1.0 INTRODUCTION Inside today’s computers, data is represented as 1’s and 0’s. These 1’s and 0’s might be stored magnetically on a disk, or as a state in a transistor, core, or vacuum tube. To perform useful operations on these 1’s and 0’s one have to organize them together into patterns that make up codes. Modern digital systems do not represent numeric values using the decimal system. Instead, they typically use a binary or two’s complement numbering system. To understand the digital system arithmetic, one must understand how digital systems represent numbers. This chapter discusses several important concepts including the binary, octal and hexadeci- mal numbering systems, binary data organization (bits, nibbles, bytes, words, and double words), signed and unsigned numbering systems. If one is already familiar with these terms he should at least skim this material. 1.1 A REVIEW OF THE DECIMAL SYSTEM People have been using the decimal (base 10) numbering system for so long that they probably take it for granted. When one see a number like “123”, he don’t think about the value 123; rather, he generate a mental image of how many items this value represents. In reality, however, the number 123 represents: 1*102 + 2*101 + 3*100 OR 100 + 20 + 3 Each digit appearing to the left of the decimal point represents a value between zero and nine times an increasing power of ten. Digits appearing to the right of the decimal point represent a value between zero and nine times an increasing negative power of ten.
    [Show full text]
  • An Empirical Analysis of the Ipv4 Number Market
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Illinois Digital Environment for Access to Learning and Scholarship Repository Buying numbers: An Empirical Analysis of the IPv4 Number Market Milton L. Mueller Brenden Kuerbis Syracuse University Syracuse University [email protected] and University of Toronto [email protected] Abstract The emergence of a trading market for previously allocated Internet number blocks is an important change in Internet governance. Almost all of the Internet’s 32-bit address space has been given out, and we have not migrated to a new internet protocol, IPv6, with a larger address space. IP addresses are therefore being commoditized, as organizations with surplus numbers sell address blocks to organizations that want more. Though controversial, we know little about this phenomenon. This paper quantifies the number of address blocks that have been traded as of July 2012 and analyzes the scant information that exists about the pricing of these resources, discovering the emergence of a billion dollar market. The paper then shows how this factual information relates to key policy debates, in particularly the role of needs assessment and property rights in IPv4 number blocks. Keywords: Internet governance, IP address markets, IPv4 scarcity, IPv6 migration, property rights Introduction One of the most important but least-studied aspects of Internet policy is the emergence of a trading market for previously allocated Internet number blocks. Without unique Internet protocol numbers for the networks and devices attached, the Internet simply doesn’t work. The original Internet Protocol standard, known as IPv4, specified a 32-bit numbering space, which provided slightly less than 4 billion unique numbers that could be used as addresses (Postel, 1981).
    [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]