A Brief History of TI Object File Formats

From Texas Instruments Embedded Processors Wiki

Jump to: navigation, search

Translate this page to

Introduction

A better title for this article is Overview of TI Object File Formats. But that's boring. This article brings together the basics about object file formats used by TI code generation tools.

An object file contains the binary representation of the code to be executed. An object file format specifies the organization of the information in the file. An Internet search on those terms yields lots of good background information.

COFF: Common Object File Format

The default object file format is called COFF, which stands for Common Object File Format. It was first used in early Unix systems. COFF is not an industry standard. TI adopted COFF from Unix, then started customizing it. This pattern occurred at other companies as well, including MicroSoft. So, while TI and MicroSoft both use COFF, the resulting object files are in no way compatible.

The best documentation on the TI variant of COFF is this application note: tidoc:spraao8 . Note there is not enough information in that application note to write your own COFF handling code. See #Processing Object Files for that.

ELF: Executable and Linking Format

TI is introducing a new object file format named ELF, which stands for Executable and Linking Format. Currently the TI ARM compiler and C6000 compiler can generate ELF. By default, the compiler still generates COFF. The switch --abi=eabi changes the application binary interface (ABI) to EABI, which includes, among other things, use of ELF format.

In the future, other TI compilers will optionally generate ELF. Whether ELF ever completely replaces COFF remains to be seen. If that happens, it will take years. Nonetheless, there is reason to expect ELF to prevail long term. TI supports, or will support, several modern code generation tools features such as COMDAT sections, early template instantiation, and dynamic linking only with ELF, and not COFF.

Is ELF an industry standard? Well, there is no standards body behind it such as the ANSI committees behind the C and C++ standards. Nonetheless, it is much closer to a standard than COFF. It is fairly easy to encode information in an ELF file that only TI tools recognize, and other tools safely ignore. Thus the GNU utility readelf can be used to inspect TI generated ELF files. Conversely, TI tools can read Linux ELF files. Here is an example using ofd470, the object file display utility from the ARM toolset:

% ofd470 /bin/ls | less

OBJECT FILE:  /bin/ls

 Object File Information

    File Name:           /bin/ls
    Format:              ELF Version 1
    File Type:           executable file
    Machine:             Intel 80386
    Machine Endian:      little endian
    Entry Point:         0x080498c0
    Number of Sections:  26
    File Length:         67700
    ELF Class:           32-bit objects
    ELF e_flags:         0x00000000

 Program Segment Table
 ...

The best way to find an ELF specification is by starting with TI documentation. The ARM compiler book is here: tidoc:spnu151 . The section titled Application Binary Interface includes a link to the specification for EABI. From there, you can find a current specification for ELF. (Sorry this is a bit inconvenient. But anything else is likely to go stale, out of date, or worse. As of 4/22/2009, here is the ELF for the ARM Architecture document.)

Processing Object Files

So, you want to do some kind of processing on TI object files. Because reading specs and parsing binary files is neither fun nor productive, TI provides the Object File Display utility. The ARM toolset utility is named ofd470. Other toolsets have a utility with a similar name. It is documented in the Assembly Language Tools Book for your toolset. If that is not handy, here is the ARM one: tidoc:spnu118.

As seen in the example above, lots of information can be obtained with default options. You can get that same information in XML format by using -x. And you can process that XML data with a package described in this Wiki article: Code Generation Tools XML Processing Scripts .

These are much better options than creating your own custom solution.

Debug Information Format

Object files commonly contain information read by a debugger (such as CCS) to do things such as associate an address with a line of source code. Because of this relationship, it is common to think debug information is another detail of the object file format. It isn't. The format of the debug information is specified separately. It is better to think of the debug information as a separate concept that just happens to be encoded within an object file. In theory, an object file may contain debug information encoded in any format.

As of this writing, the default debug format used by TI compilers is DWARF version 2. This probably merits a separate Wiki article. But for now, here are a few links.

TI specific information on DWARF: tidoc:spraab5
The Impact of DWARF on TI Object Files Errata (SPRAAB5)
DWARF standard

For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article A Brief History of TI Object File Formats here.