SPRAB89A September   2011  – March 2014

 

  1. 1 Introduction
    1. 1.1  ABIs for the C6000
    2. 1.2  Scope
    3. 1.3  ABI Variants
    4. 1.4  Toolchains and Interoperability
    5. 1.5  Libraries
    6. 1.6  Types of Object Files
    7. 1.7  Segments
    8. 1.8  C6000 Architecture Overview
    9. 1.9  Reference Documents
    10. 1.10 Code Fragment Notation
  2. 2 Data Representation
    1. 2.1 Basic Types
    2. 2.2 Data in Registers
    3. 2.3 Data in Memory
    4. 2.4 Complex Types
    5. 2.5 Structures and Unions
    6. 2.6 Arrays
    7. 2.7 Bit Fields
      1. 2.7.1 Volatile Bit Fields
    8. 2.8 Enumeration Types
  3. 3 Calling Conventions
    1. 3.1 Call and Return
      1. 3.1.1 Return Address Computation
      2. 3.1.2 Call Instructions
      3. 3.1.3 Return Instruction
      4. 3.1.4 Pipeline Conventions
      5. 3.1.5 Weak Functions
    2. 3.2 Register Conventions
    3. 3.3 Argument Passing
    4. 3.4 Return Values
    5. 3.5 Structures and Unions Passed and Returned by Reference
    6. 3.6 Conventions for Compiler Helper Functions
    7. 3.7 Scratch Registers for Inter-Section Calls
    8. 3.8 Setting Up DP
  4. 4 Data Allocation and Addressing
    1. 4.1 Data Sections and Segments
    2. 4.2 Allocation and Addressing of Static Data
      1. 4.2.1 Addressing Methods for Static Data
        1. 4.2.1.1 Near DP-Relative Addressing
        2. 4.2.1.2 Far DP-Relative Addressing
        3. 4.2.1.3 Absolute Addressing
        4. 4.2.1.4 GOT-Indirect Addressing
        5. 4.2.1.5 PC-Relative Addressing
      2. 4.2.2 Placement Conventions for Static Data
        1. 4.2.2.1 Abstract Conventions for Placement
        2. 4.2.2.2 Abstract Conventions for Addressing
        3. 4.2.2.3 Linker Requirements
      3. 4.2.3 Initialization of Static Data
    3. 4.3 Automatic Variables
    4. 4.4 Frame Layout
      1. 4.4.1 Stack Alignment
      2. 4.4.2 Register Save Order
        1. 4.4.2.1 Big-Endian Pair Swapping
        2. 4.4.2.2 Examples
      3. 4.4.3 DATA_MEM_BANK
      4. 4.4.4 C64x+ Specific Stack Layouts
        1. 4.4.4.1 _ _C6000_push_rts Layout
        2. 4.4.4.2 Compact Frame Layout
    5. 4.5 Heap-Allocated Objects
  5. 5 Code Allocation and Addressing
    1. 5.1 Computing the Address of a Code Label
      1. 5.1.1 Absolute Addressing for Code
      2. 5.1.2 PC-Relative Addressing
      3. 5.1.3 PC-Relative Addressing Within the Same Section
      4. 5.1.4 Short-Offset PC-Relative Addressing (C64x)
      5. 5.1.5 GOT-Based Addressing for Code
    2. 5.2 Branching
    3. 5.3 Calls
      1. 5.3.1 Direct PC-Relative Call
      2. 5.3.2 Far Call Trampoline
      3. 5.3.3 Indirect Calls
    4. 5.4 Addressing Compact Instructions
  6. 6 Addressing Model for Dynamic Linking
    1. 6.1 Terms and Concepts
    2. 6.2 Overview of Dynamic Linking Mechanisms
    3. 6.3 DSOs and DLLs
    4. 6.4 Preemption
    5. 6.5 PLT Entries
      1. 6.5.1 Direct Calls to Imported Functions
      2. 6.5.2 PLT Entry Via Absolute Address
      3. 6.5.3 PLT Entry Via GOT
    6. 6.6 The Global Offset Table
      1. 6.6.1 GOT-Based Reference Using Near DP-Relative Addressing
      2. 6.6.2 GOT-Based Reference Using Far DP-Relative Addressing
    7. 6.7 The DSBT Model
      1. 6.7.1 Entry/Exit Sequence for Exported Functions
      2. 6.7.2 Avoiding DP Loads for Internal Functions
      3. 6.7.3 Function Pointers
      4. 6.7.4 Interrupts
      5. 6.7.5 Compatibility With Non-DSBT Code
    8. 6.8 Performance Implications of Dynamic Linking
  7. 7 Thread-Local Storage Allocation and Addressing
    1. 7.1 About Multi-Threading and Thread-Local Storage
    2. 7.2 Terms and Concepts
    3. 7.3 User Interface
    4. 7.4 ELF Object File Representation
    5. 7.5 TLS Access Models
      1. 7.5.1 C6x Linux TLS Models
        1. 7.5.1.1 General Dynamic TLS Access Model
        2. 7.5.1.2 Local Dynamic TLS Access Model
        3. 7.5.1.3 Initial Exec TLS Access Model
          1. 7.5.1.3.1 Thread Pointer
          2. 7.5.1.3.2 Initial Exec TLS Addressing
        4. 7.5.1.4 Local Exec TLS Access Model
      2. 7.5.2 Static Executable TLS Model
        1. 7.5.2.1 Static Executable Addressing
        2. 7.5.2.2 Static Executable TLS Runtime Architecture
        3. 7.5.2.3 Static Executable TLS Allocation
          1. 7.5.2.3.1 TLS Initialization Image Allocation
          2. 7.5.2.3.2 Main Thread’s TLS Allocation
          3. 7.5.2.3.3 Thread Library’s TLS Region Allocation
        4. 7.5.2.4 Static Executable TLS Initialization
          1. 7.5.2.4.1 Main Thread’s TLS Initialization
          2. 7.5.2.4.2 TLS Initialization by Thread Library
        5. 7.5.2.5 Thread Pointer
      3. 7.5.3 Bare-Metal Dynamic Linking TLS Model
        1. 7.5.3.1 Default TLS Addressing for Bare-Metal Dynamic Linking
        2. 7.5.3.2 TLS Block Creation
    6. 7.6 Thread-Local Symbol Resolution and Weak References
      1. 7.6.1 General and Local Dynamic TLS Weak Reference Addressing
      2. 7.6.2 Initial and Local Executable TLS Weak Reference Addressing
      3. 7.6.3 Static Exec and Bare Metal Dynamic TLS Model Weak References
  8. 8 Helper Function API
    1. 8.1 Floating-Point Behavior
    2. 8.2 C Helper Function API
    3. 8.3 Special Register Conventions for Helper Functions
    4. 8.4 Helper Functions for Complex Types
    5. 8.5 Floating-Point Helper Functions for C99
  9. 9 Standard C Library API
    1. 9.1  Reserved Symbols
    2. 9.2  <assert.h> Implementation
    3. 9.3  <complex.h> Implementation
    4. 9.4  <ctype.h> Implementation
    5. 9.5  <errno.h> Implementation
    6. 9.6  <float.h> Implementation
    7. 9.7  <inttypes.h> Implementation
    8. 9.8  <iso646.h> Implementation
    9. 9.9  <limits.h> Implementation
    10. 9.10 <locale.h> Implementation
    11. 9.11 <math.h> Implementation
    12. 9.12 <setjmp.h> Implementation
    13. 9.13 <signal.h> Implementation
    14. 9.14 <stdarg.h> Implementation
    15. 9.15 <stdbool.h> Implementation
    16. 9.16 <stddef.h> Implementation
    17. 9.17 <stdint.h> Implementation
    18. 9.18 <stdio.h> Implementation
    19. 9.19 <stdlib.h> Implementation
    20. 9.20 <string.h> Implementation
    21. 9.21 <tgmath.h> Implementation
    22. 9.22 <time.h> Implementation
    23. 9.23 <wchar.h> Implementation
    24. 9.24 <wctype.h> Implementation
  10. 10C++ ABI
    1. 10.1  Limits (GC++ABI 1.2)
    2. 10.2  Export Template (GC++ABI 1.4.2)
    3. 10.3  Data Layout (GC++ABI Chapter 2)
    4. 10.4  Initialization Guard Variables (GC++ABI 2.8)
    5. 10.5  Constructor Return Value (GC++ABI 3.1.5)
    6. 10.6  One-Time Construction API (GC++ABI 3.3.2)
    7. 10.7  Controlling Object Construction Order (GC++ ABI 3.3.4)
    8. 10.8  Demangler API (GC++ABI 3.4)
    9. 10.9  Static Data (GC++ ABI 5.2.2)
    10. 10.10 Virtual Tables and the Key function (GC++ABI 5.2.3)
    11. 10.11 Unwind Table Location (GC++ABI 5.3)
  11. 11Exception Handling
    1. 11.1  Overview
    2. 11.2  PREL31 Encoding
    3. 11.3  The Exception Index Table (EXIDX)
      1. 11.3.1 Pointer to Out-of-Line EXTAB Entry
      2. 11.3.2 EXIDX_CANTUNWIND
      3. 11.3.3 Inlined EXTAB Entry
    4. 11.4  The Exception Handling Instruction Table (EXTAB)
      1. 11.4.1 EXTAB Generic Model
      2. 11.4.2 EXTAB Compact Model
      3. 11.4.3 Personality Routines
    5. 11.5  Unwinding Instructions
      1. 11.5.1 Common Sequence
      2. 11.5.2 Byte-Encoded Unwinding Instructions
      3. 11.5.3 24-Bit Unwinding Encoding
    6. 11.6  Descriptors
      1. 11.6.1 Encoding of Type Identifiers
      2. 11.6.2 Scope
      3. 11.6.3 Cleanup Descriptor
      4. 11.6.4 Catch Descriptor
      5. 11.6.5 Function Exception Specification (FESPEC) Descriptor
    7. 11.7  Special Sections
    8. 11.8  Interaction With Non-C++ Code
      1. 11.8.1 Automatic EXIDX Entry Generation
      2. 11.8.2 Hand-Coded Assembly Functions
    9. 11.9  Interaction With System Features
      1. 11.9.1 Shared Libraries
      2. 11.9.2 Overlays
      3. 11.9.3 Interrupts
    10. 11.10 Assembly Language Operators in the TI Toolchain
  12. 12DWARF
    1. 12.1 DWARF Register Names
    2. 12.2 Call Frame Information
    3. 12.3 Vendor Names
    4. 12.4 Vendor Extensions
  13. 13ELF Object Files (Processor Supplement)
    1. 13.1 Registered Vendor Names
    2. 13.2 ELF Header
    3. 13.3 Sections
      1. 13.3.1 Section Indexes
      2. 13.3.2 Section Types
      3. 13.3.3 Extended Section Header Attributes
      4. 13.3.4 Subsections
      5. 13.3.5 Special Sections
      6. 13.3.6 Section Alignment
    4. 13.4 Symbol Table
      1. 13.4.1 Symbol Types
      2. 13.4.2 Common Block Symbols
      3. 13.4.3 Symbol Names
      4. 13.4.4 Reserved Symbol Names
      5. 13.4.5 Mapping Symbols
    5. 13.5 Relocation
      1. 13.5.1 Relocation Types
      2. 13.5.2 Relocation Operations
      3. 13.5.3 Relocation of Unresolved Weak References
  14. 14ELF Program Loading and Dynamic Linking (Processor Supplement)
    1. 14.1 Program Header
      1. 14.1.1 Base Address
      2. 14.1.2 Segment Contents
      3. 14.1.3 Bound and Read-Only Segments
      4. 14.1.4 Thread-Local Storage
    2. 14.2 Program Loading
    3. 14.3 Dynamic Linking
      1. 14.3.1 Program Interpreter
      2. 14.3.2 Dynamic Section
      3. 14.3.3 Shared Object Dependencies
      4. 14.3.4 Global Offset Table
      5. 14.3.5 Procedure Linkage Table
      6. 14.3.6 Preemption
      7. 14.3.7 Initialization and Termination
    4. 14.4 Bare-Metal Dynamic Linking Model
      1. 14.4.1 File Types
      2. 14.4.2 ELF Identification
      3. 14.4.3 Visibility and Binding
      4. 14.4.4 Data Addressing
      5. 14.4.5 Code Addressing
      6. 14.4.6 Dynamic Information
  15. 15Linux ABI
    1. 15.1  File Types
    2. 15.2  ELF Identification
    3. 15.3  Program Headers and Segments
    4. 15.4  Data Addressing
      1. 15.4.1 Data Segment Base Table (DSBT)
      2. 15.4.2 Global Offset Table (GOT)
    5. 15.5  Code Addressing
    6. 15.6  Lazy Binding
    7. 15.7  Visibility
    8. 15.8  Preemption
    9. 15.9  Import-as-Own Preemption
    10. 15.10 Program Loading
    11. 15.11 Dynamic Information
    12. 15.12 Initialization and Termination Functions
    13. 15.13 Summary of the Linux Model
  16. 16Symbol Versioning
    1. 16.1 ELF Symbol Versioning Overview
    2. 16.2 Version Section Identification
  17. 17Build Attributes
    1. 17.1 C6000 ABI Build Attribute Subsection
    2. 17.2 C6000 Build Attribute Tags
  18. 18Copy Tables and Variable Initialization
    1. 18.1 Copy Table Format
    2. 18.2 Compressed Data Formats
      1. 18.2.1 RLE
      2. 18.2.2 LZSS Format
    3. 18.3 Variable Initialization
  19. 19Extended Program Header Attributes
    1. 19.1 Encoding
    2. 19.2 Attribute Tag Definitions
    3. 19.3 Extended Program Header Attributes Section Format
  20. 20Revision History

6.7 The DSBT Model

Each executable that shares a library's code must allocate its own private copy of the library's data. Furthermore, each static link unit's own data (including the GOT) is addressed using DP-relative addressing, with offsets that are fixed at static link time. (On systems with MMU's, this is typically accomplished by using PC-relative addressing to achieve position-independent virtual offsets, and using address translation to instantiate multiple physical copies of the data segment at the same (virtual) address.) Systems without an MMU, like the C6000, typically rely on some form of a static base pointer of some kind (the DP) and offset addressing.

All addressing from a given static link unit is relative to its data segment and is therefore independent of any other static link unit. The result is a model where a given program, comprised of an executable and one or more (possibly shared) libraries, has multiple data segments, each having a different address on which DP-relative offsets are based. When control transfers from one module to another, the DP must be changed to the base address of the new module's data segment.

The general issues with this model, common to most static-base addressing schemes, are:

  • Who changes the DP: the caller, or the callee
  • How is the new DP value determined
  • How are indirect calls handled

Various solutions have been adopted for other architectures, such as FDPIC, XFLAT, and DSBT. We have chosen to adopt the DSBT model as the best compromise between efficiency, compatibility, and flexibility.

When a call to an imported function is made, the callee is responsible for setting the DP to point to its data segment (more precisely, the underlying executable's private copy of the data segment for the module containing the callee), and for restoring it upon return.

Before we explain how the callee achieves this, consider two observations. First, each module has its own data segment(s), with its own base address, and if shared among multiple executables, each has a private copy of that segment, with a different base address. Furthermore, these addresses are dynamically determined. So obviously, much like addresses stored in the GOT, the base address cannot be absolute and therefore must be stored in the data segment.

Second, although the callee is responsible for changing the DP, upon entry to the callee the DP is still pointing to the caller's data segment. Thus the callee has only the context of the caller to somehow set up its own DP.

The solution is that the first few words of each data segment contain a copy of a table, called the Data Segment Base Table (DSBT), listing the base addresses for all the other segments of the other modules that comprise the program. Each shared library is assigned a unique index, starting with 1. Index 0 is reserved for the executable. The callee uses its assigned index to lookup its own base address in the caller's copy of the table, and assigns that value to the DP. Within the private data segments for a given executable and its shared libraries, each copy of the DSBT is identical, enabling any callee to use any caller's table to find its own base address.

The DSBT approach has the desirable characteristic that the penalty for dynamic linking is isolated to exported functions. There is no effect on the ABI for bare-metal programs that do not use dynamic linking, or for an executable without exported functions. By judiciously using toolchain-specific declaration constructs to explicitly identify externally-accessible functions (see Section 6.8.2), the programmer can minimize the overhead. In functions that do need to adjust the DP, the overhead is typically only 3 instructions.

The DSBT model's drawback is the requirement to coordinate assignment of library indexes and to enforce agreement on the maximum number of modules, which determines the size of the table in each data segment.

The DSBT is allocated by the static linker in the .dsbt section, and must be located at the base address of each module's first DP-relative segment so that the DP points to it. The dynamic linker initializes the table entries when the module is loaded.

An executable always accesses the table using index 0; library indexes start at 1, 2, or some other index as specified for a specific platform. A library's index may be assigned in one of two ways:

  • It can be statically assigned at static link time (or equivalently, by a static post-link tool) via a command line option or other directive. This method must be used when the library is ROM-resident and cannot be relocated at dynamic load time.
  • It can be dynamically assigned by the dynamic linker. This requires relocating (patching) the library's code segment when it is loaded, in order to update the indexes, so libraries with dynamically-assigned indexes are not considered position independent.

Each object's DSBT must be at least as large as the largest index assigned to any module that is dynamically loaded as part of the program. The dynamic linker is responsible for ensuring that all modules have a large enough DSBT; if not, it must fail to load the program. The size of the DSBT is specified at static link time (or to a static post-link tool) via a command line option or environment variable. Embedded systems generally require a small number of dynamic libraries; so a typical size for the DSBT is 5 or less.

The module's dynamic section contains C6000-specific tags that specify the size of its DSBT table, and its index if assigned. These are detailed in Section 14.4.2.