64-bit ELF Object File Specification - Draft Version 2.5 MIPS Technologies / Silicon Graphics Computer Systems
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
64-bit ELF Object
File Specification
Draft Version 2.5
MIPS Technologies /
Silicon Graphics Computer Systems
Caveat: This document represents work in progress. It is incomplete and
subject to change. In particular, lists of constants, sections, and attributes
are may be incomplete or inaccurate in detail. Reference to the header
files elf.h and sys/elf.h is recommended before reliance on the informa-
tion herein.
Section 1 Introduction
This document specifies the format of MIPS object files for 64-bit code.
We assume as a basis the documents [ABI32], [ABI32M], and [ABI64].
In addition, Silicon Graphics uses the DWARF debugging information
format as specified in [DWARF]. Information in those documents should
be considered valid unless contradicted here.
The remainder of this section summarizes our objectives, approach, and
open issues. Section 2 corresponds to ABI Section 4, describing ELF-64Page 2 007-4658-001
object files, and Section 3 corresponds to ABI Section 5, describing pro-
gram loading and dynamic linking. Section 4 describes the 64-bit archive
file format (from MIPS ABI Section 7), though it is not technically part
of ELF.
1.1 Objectives
The objectives of this format definition fall in two categories. The first is
simply to extend the base 32-bit ELF format, by increasing field sizes
where appropriate, so that there will be no problems dealing with very
large 64-bit programs. The second is to extend the kinds of information
included in the object file to facilitate new features.
1. Remove 32-bit constraints on object file sizes.
2. Support checking and potential conversion of subprogram call in-
terfaces.
3. Support efficient and reliable application of performance monitor-
ing tools like pixie and object code optimization tools like cord.
4. Support efficient and reliable debugging facilities.
1.2 Approach
We start from the basis of the System V ABI and the MIPS symbol table
format, extending them in the obvious ways to support very large objects.
We will then add additional information (generally new sections) to sup-
port the extended objectives described above. We generally recognize
three levels of support:
1. Some information is required for all ABI-compliant object files.
2. Some information is optional, but its absence will prevent use of
system functionality, e.g. cache optimization reordering, etc.
3. Some information is entirely optional; its absence interferes only
with functionality unrelated to program construction, e.g. debug-
ging, performance measurement, etc.
To clarify the distinction between these levels, we have defined a new
section header flag, SHF_MIPS_NOSTRIP, which is applied to sections in
the first two levels. The intent is that a strip(1) tool or its equivalent
should never remove these sections by default, and should warn the user
if their removal is explicitly requested.
We have followed a number of principles and assumptions in this specifi-
cation:007-4658-001 Introduction Page 3
1. Sections expected to be used by runtime facilities, e.g. stack trace-
back, have the SHF_ALLOC attribute. Such sections also have sym-
bols automatically generated by the linker which may be used to
reference them in code (see Section 3.1.2). This allows simple vir-
tual addressing in the process address space for any required ac-
cess.
2. Sections are NOT given the SHF_WRITE attribute simply because
rld may need to relocate their contents. We assume that rld can re-
quest write access and change it back if necessary, and prefer this
approach for a more robust runtime environment.
3. We require that the executable code for a single executable or DSO
will never be larger than 256MB, and that it will never be loaded
across a 256MB boundary. This requirement allows various benefi-
cial assumptions about valid addressing code within an execut-
able/DSO, and also allows the use of single-word addresses (to be
interpreted relative to the containing 4GB address range) for code
in an object file.
Finally, this is intended to be a permissive specification. Usage of the fea-
tures described should generally be viewed as permitted in any combina-
tion with a reasonably unambiguous interpretation unless it is forbidden.
It is likely, of course, that new usage will uncover (and break) implicit as-
sumptions in tools from time to time, and adding further restrictions may
be the most appropriate solution, but the bias should be towards fixing the
tools to allow reasonable practices.
1.3 Conventions
In all of the tables in this document, unshaded information is that derived
directly from external documents (i.e. the generic ABI and the DWARF
specification), lightly shaded information is derived directly from 32-bit
MIPS specifications (ELF, header files), and heavily shaded information
is new or substantially changed from these existing formats.
We use the usual wording to describe requirements, distinguishing be-
tween must (mandatory), should (recommended), and may (allowed).
1.4 Open Issues
Unresolved issues and missing information are marked in this document
ISSUE !
by the symbol at the left. The most significant ones at this time are:Page 4 007-4658-001
1. Should there be a distinct EK_PBEGIN event in case a program
unit does not begin with an entrypoint (Section 2.10)?
2. Should memory events be segregated to a distinct events section so
that tools which use the default events and those which use the
memory events aren’t impacted by the other data (Section 2.10)?
1.5 Changes from Version 2.0
The following have been changed from version 2.0 of this specification:
1. Added a description of LEB128/ULEB128 formats.
2. Added EF_MIPS_OPTIONS_FIRST and EF_MIPS_ARCH_ASE ELF
flags.
3. Added Table 15 describing special reserved values of the st_shndx
field.
4. Added definitions of OHW_R8KPFETCH and OHW_R5KEOP masks
in the Hardware Patch Option Descriptor. Added new Hardware
AND/OR Patch Option Descriptors.
5. Added new ODK_GP_GROUP and ODK_IDENT option descriptors.
6. Note that R_MIPS_PJUMP requires that ld check that the symbol is
not preemptible before performing the relocation.
7. Added definitions of event kinds EK_LTR_FCALL and
EK_PCREL_GOT0. Fixed values of kinds EK_MEM_*.
8. Fixed definition of content kind CK_GP_GROUP.
9. Added section on Shared Object Dependencies describing default
search paths for DSOs and environment variables to override them.
10. Added sections defining the .msym and .conflict sections for the
quickstart discusion (Section 3.8).
11. Added DT_MIPS_INTERFACE_SIZE and
DT_MIPS_RLD_TEXT_RESOLVE_ADDR descriptions.
12. Added missing DT_MIPS_FLAGS flags.
13. Added documentation of the .liblist section (Section 3.8.2).
14. Added documentation of the .MIPS.symlib section (Section 3.8.4).
15. Corrected default library search paths in Section 3.4.
16. Added SHN_MIPS_LCOMMON (thread-local common) and
SHN_MIPS_LCOMMON (thread-local undefined) symbol documen-
tation in Section 2.5.
17. Added STO_OPTIONAL symbol documentation in Section 2.5.007-4658-001 Introduction Page 5
18. Added split common symbol documentation in Section 2.5 (and
Section 2.5.1).
19. Fixed EK_PCREL_GOT0 definition in Section 2.10.
20. Clarified CK_GP_GROUP description in Section 2.12.
21. Add comment to ODK_PAD option descriptor, allowing implemen-
tations to require that ld do all padding rather than leaving some to
rld (Section 2.8).
22. Added ODK_PAGESIZE proposal (Section 2.8.10).Page 6 007-4658-001
Section 2 ELF-64 Object File Format
The ELF-64 object file format is based on the document [ABI64]. The
relevant declarations are contained in the header file /usr/include/elf.h.
(Note that /usr/include/sys/elf.h is logically part of /usr/include/elf.h, and
is the actual location of most of these declarations.)
We call attention to the [ABI32] requirement that all data structures be
naturally aligned in the file (see p. 4-3). This implies that all headers, sec-
tions, and other major components must be 8-byte aligned, with padding
if necessary to accomplish this. Although 4-byte alignment is probably
ELF-32
adequate currently for ELF-32, 8-byte alignment should also be used
there to avoid future extension problems. (Note, however, that the
DWARF specification fundamentally assumes a byte-stream format.
Therefore, the data structures contained in some DWARF sections will
violate the alignment requirement. In addition, the .MIPS.events and .MI-
PS.content sections have packed byte-stream contents for compactness.)
When defining structure fields which are smaller than a convenient stor-
age unit (e.g. single-bit flags), we have used C’s bitfield notation (e.g.
Elf64_Word:1). The intent is to specify layout equivalent to big-endian
bitfields, but the actual structure declarations in header files should use
masks and shifts to access them. This avoids problems with byte swap-
ping between big- and little-endian hosts.
2.1 Infrastructure
ELF-64 is defined in terms of the types in Table 1:
Table 1 ELF-64 Data Types
Name Size Alignment Purpose
Elf64_Addr 8 8 Unsigned program address
Elf64_Half 2 2 Unsigned small integer
Elf64_Off 8 8 Unsigned file offset
Elf64_Sword 4 4 Signed medium integer
Elf64_Sxword 8 8 Signed large integer007-4658-001 ELF-64 Object File Format Page 7
Table 1 ELF-64 Data Types
Name Size Alignment Purpose
Elf64_Word 4 4 Unsigned medium integer
Elf64_Xword 8 8 Unsigned large integer
Elf64_Byte 1 1 Unsigned tiny integer
Elf64_Section 2 2 Section index (unsigned)
There are places in ELF-64 files where fundamental data types must be
encoded, for instance in subprogram interface descriptors. We generally
use the constants in Table 2 to identify them, based on DWARF version 1
(but not identical).
Table 2 Fundamental Data Types
Name(s) Value Comments
FT_unknown 0x0001 unknown type
FT_signed_char 0x0001 8-bit signed character
FT_unsigned_char 0x0002 8-bit unsigned character
FT_signed_short 0x0003 16-bit signed short integer
FT_unsigned_short 0x0004 16-bit unsigned short integer
FT_signed_int32 0x0005 32-bit signed integer
FT_unsigned_int32 0x0006 32-bit unsigned integer
FT_signed_int64 0x0007 64-bit signed integer
FT_unsigned_int64 0x0008 64-bit unsigned integer
FT_pointer32 0x0009 32-bit pointer
FT_pointer64 0x000a 64-bit pointer
FT_float32 0x000b 32-bit floating point (IEEE)
FT_float64 0x000c 64-bit floating point (IEEE)
FT_float128 0x000d 128-bit floating point
FT_complex64 0x000e 64-bit complex floating point
FT_complex128 0x000f 128-bit complex floating pointPage 8 007-4658-001
Table 2 Fundamental Data Types
Name(s) Value Comments
FT_complex256 0x0010 256-bit complex floating point
FT_void 0x0011 void
FT_bool32 0x0012 32-bit Boolean (TRUE or FALSE)
FT_bool64 0x0013 64-bit Boolean (TRUE or FALSE)
FT_label32 0x0014 32-bit label (address)
FT_label64 0x0015 64-bit label (address)
FT_struct 0x0020 structure (record)
FT_union 0x0021 union (variant)
FT_enum 0x0022 enumerated type
FT_typedef 0x0023 typedef
FT_set 0x0024 Pascal: set
FT_range 0x0025 Pascal: subrange of integer
FT_member_ptr 0x0026 C++: member pointer
FT_virtual_ptr 0x0027 C++: virtual pointer
FT_class 0x0028 C++: class
The fundamental types in Table 2 may be modified by the qualifiers in
Table 3 below, also based on [DWARF-1]:
Table 3 Type Qualifiers
Name Value Comments
MOD_pointer_to 0x01 pointer to base type
MOD_reference_to 0x02 C++: reference to base type
MOD_const 0x03 const
MOD_volatile 0x04 volatile
MOD_lo_user 0x80 first MIPS-specific modifier
MOD_function 0x80 function returning base type
MOD_array_of 0x81 array of base type007-4658-001 ELF-64 Object File Format Page 9
Table 3 Type Qualifiers
Name Value Comments
MOD_hi_user 0xff last MIPS-specific modifier
The data structures in the .MIPS.events and .MIPS.content sections use
compressed types from the [DWARF] specification, named LEB128 and
ULEB128, for (Unsigned) Little-Endian Base 128 numbers. These are
"little endian" only in the sense that they avoid using space to represent
the "big" end of an integer when the big end is all zeroes (unsigned) or
sign extension bits (signed).
ULEB128 numbers are encoded as follows: start at the low-order end of
an unsigned integer and chop it into 7-bit chunks. Place each chunk into
the low-order 7 bits of a byte. Typically, several of the high-order bytes
will be zero (unsigned) or copies of the sign bit (signed) — discard them.
Emit the remaining bytes in a stream, starting with the low-order byte; set
the high order bit on each byte except the last emitted byte. The high bit
of zero on the last byte indicates to the decoder that it has encountered
the last byte.
2.2 ELF-64 Header
The header format is as defined in [ABI64]; it is reproduced here for ref-
erence purposes.
Table 4 ELF-64 Header Structure
Field Name Type Comments
e_ident[EI_NIDENT] unsigned char See Table 5
e_type Elf64_Half See [ABI32]
e_machine Elf64_Half Machine (EM_MIPS = 8)
e_version Elf64_Word File format version
e_entry Elf64_Addr Process entry address
e_phoff Elf64_Off Program header table file offset
e_shoff Elf64_Off Section header table file offsetPage 10 007-4658-001
Table 4 ELF-64 Header Structure
Field Name Type Comments
e_flags Elf64_Word Flags — see Table 6
e_ehsize Elf64_Half ELF header size (bytes)
e_phentsize Elf64_Half Program header entry size
e_phnum Elf64_Half Number of program headers
e_shentsize Elf64_Half Section header entry size
e_shnum Elf64_Half Number of section headers
e_shstrndx Elf64_Half Section name string table sec-
tion header index
The structure of the e_ident field is given by Table 5.
Table 5 ELF-64 Header: e_ident[ ] Contents
Offset Name Index Value or Interpretation
EI_MAG0-3 0-3 Magic string: 0x7f, ’E’, ’L’, ’F’
EI_CLASS 4 Class of format: ELFCLASS64 = 2
EI_DATA 5 Endianness: ELFDATAMSB = 2
EI_VERSION 6 Version of format: EV_CURRENT = 1
EI_PAD 7-15 Reserved, must be zero
Flags currently defined for the e_flags field are given by .
Table 6 ELF-64 Header: Processor-Specific Flags in e_flags
Flag Name Value Comments
EF_MIPS_NOREORDER 0x00000001 At least one .noreorder assembly directive ap-
peared in a source contributing to the object
EF_MIPS_PIC 0x00000002 This file contains position-independent code007-4658-001 ELF-64 Object File Format Page 11
Table 6 ELF-64 Header: Processor-Specific Flags in e_flags
Flag Name Value Comments
EF_MIPS_CPIC 0x00000004 This file’s code follows standard conventions for
calling position-independent code
EF_MIPS_UCODE 0x00000010 This file contains UCODE (obsolete)
EF_MIPS_ABI2 0x00000020 This file follows the MIPS III 32-bit ABI. (Its
EI_CLASS will be ELFCLASS32.)
EF_MIPS_OPTIONS_FIRST 0x00000080 This .MIPS.options section in this file contains
one or more descriptors, currently types
ODK_GP_GROUP and/or ODK_IDENT,
which should be processed first by ld.
EF_MIPS_ARCH_ASE 0x0f000000 Application-specific architectural extensions
used by this object file:
EF_MIPS_ARCH_ASE_MDMX 0x08000000 Uses MDMX multimedia extensions
EF_MIPS_ARCH_ASE_M16 0x04000000 Uses MIPS-16 ISA extensions
EF_MIPS_ARCH 0xf0000000 Architecture assumed by code in this file, given
by the value of the 4-bit field selected by the
mask: MIPS I (0), MIPS II (1), MIPS III (2),
MIPS IV (3)
NOTE: PIC code is inherently CPIC, and may or may not set
EF_MIPS_CPIC.Page 12 007-4658-001
2.3 ELF-64 Section Header
The section header format is as defined in [ABI64]; it is reproduced here
for reference purposes.
Table 7 Section Header Structure (Elf64_Shdr)
Name Type Description
sh_name Elf64_Word Section name (index into section
header string table section)
sh_type Elf64_Word Section type: see Table 8
sh_flags Elf64_Xword Section flags: see Table 9
sh_addr Elf64_Addr Address of first byte, or zero
sh_offset Elf64_Off File offset of section
sh_size Elf64_Xword Section’s size in bytes
sh_link Elf64_Word Table index link: section-specific
sh_info Elf64_Word Extra information: section-specific
sh_addralign Elf64_Xword Address alignment constraint
sh_entsize Elf64_Xword Size of fixed-size entries in section,
or zero
The valid section types for section header field sh_type are given in Table
7 below. Shaded types are MIPS-specific; heavily shaded types are new
in this specification.
Table 8 Section Types
Name Value Description
SHT_NULL 0 Inactive section.
SHT_PROGBITS 1 Information defined by the program
SHT_SYMTAB 2 Symbol table (one per object file)
SHT_STRTAB 3 String table (multiple sections OK)
SHT_RELA 4 Relocation with explicit addends007-4658-001 ELF-64 Object File Format Page 13
Table 8 Section Types
Name Value Description
SHT_HASH 5 Symbol hash table (one per object)
SHT_DYNAMIC 6 Dynamic linking information
SHT_NOTE 7 Vendor-specific file information
SHT_NOBITS 8 Section contains no bits in object file
SHT_REL 9 Relocation without explicit addends
SHT_SHLIB 10 Reserved — non-conforming
SHT_DYNSYM 11 Dynamic linking symbol table (one)
SHT_LOPROC 0x70000000 First processor-specific type
SHT_HIPROC 0x7fffffff Last processor-specific type
SHT_LOUSER 0x80000000 First application-specific type
SHT_HIUSER 0x8fffffff Last application-specific type
SHT_MIPS_LIBLIST 0x70000000 DSO library information used in link
SHT_MIPS_MSYM 0x70000001 MIPS symbol table extension
Symbols conflicting with DSO-de-
SHT_MIPS_CONFLICT 0x70000002
fined symbols
SHT_MIPS_GPTAB 0x70000003 Global pointer table
SHT_MIPS_UCODE 0x70000004 Reserved
Reserved (obsolete debug informa-
SHT_MIPS_DEBUG 0x70000005
tion)
SHT_MIPS_REGINFO 0x70000006 Register usage information
SHT_MIPS_PACKAGE 0x70000007 OSF reserved
SHT_MIPS_PACKSYM 0x70000008 OSF reserved
SHT_MIPS_RELD 0x70000009 Dynamic relocation?
unused 0x7000000a
SHT_MIPS_IFACE 0x7000000b Subprogram interface information
SHT_MIPS_CONTENT 0x7000000c Section content classification
SHT_MIPS_OPTIONS 0x7000000d General options
SHT_MIPS_DELTASYM 0x7000001b Delta C++: symbol table
SHT_MIPS_DELTAINST 0x7000001c Delta C++: instance table
SHT_MIPS_DELTACLASS 0x7000001d Delta C++: class table
SHT_MIPS_DWARF 0x7000001e DWARF debug informationPage 14 007-4658-001
Table 8 Section Types
Name Value Description
SHT_MIPS_DELTADECL 0x7000001f Delta C++: declarations
SHT_MIPS_SYMBOL_LIB 0x70000020 Symbol-to-library mapping.
SHT_MIPS_EVENTS 0x70000021 Event locations
SHT_MIPS_TRANSLATE 0x70000022 ???
SHT_MIPS_PIXIE 0x70000023 Special pixie sections
SHT_MIPS_XLATE 0x70000024 Address translation tablea
SHT_MIPS_XLATE_DEBUG 0x70000025 SGI internal address translation tablea
SHT_MIPS_WHIRL 0x70000026 Intermediate code
SHT_MIPS_EH_REGION 0x70000027 C++ exception handling region info
SHT_MIPS_XLATE_OLD 0x70000028 Obsolete
Runtime procedure descriptor table
SHT_MIPS_PDR_EXCEPTION 0x70000029
exception information (ucode)
a SHT_MIPS_XLATE contains translation data table as created by the xlate library
from within cord/pixie, for use by debuggers and other tools which need to know how
to map addresses in the binary text to addresses in the debug information. See the sys-
tem header file /usr/lib/include/Xlate.h. SHT_MIPS_XLATE_DEBUG has the
same data format as SHT_MIPS_XLATE.
The section attribute flags defined for section header field sh_flags are
given in the table below. Again, light shading indicates MIPS-specific
flags, and heavier shading new flags.
Table 9 Section Attribute Flags
Name Value Description
SHF_WRITE 0x1 Section writable during execution
SHF_ALLOC 0x2 Section occupies memory
Section contains executable instruc-
SHF_EXECINSTR 0x4
tions
SHF_MASKPROC 0xf0000000 Reserved for processor-specific flags
Section must be part of global data ar-
SHF_MIPS_GPREL 0x10000000
ea.c007-4658-001 ELF-64 Object File Format Page 15
Table 9 Section Attribute Flags
Name Value Description
Section data should be merged to
SHF_MIPS_MERGE a 0x20000000
eliminate duplication
Section data is addresses by default
SHF_MIPS_ADDR 0x40000000 (see Section 2.12). Address size to be
inferred from section entry size.
Section data is string data by default
SHF_MIPS_STRING 0x80000000
(see Section 2.12).
SHF_MIPS_NOSTRIP 0x08000000 Section data may not be stripped
SHF_MIPS_LOCAL 0x04000000 Section data local to process b,c
Linker must generate implicit hidden
SHF_MIPS_NAMES 0x02000000
weak names — see Section 3.1.2
Section contains text/data which may
SHF_MIPS_NODUPE 0x01000000 be replicated in other sections. Linker
must retain only one copy.
a For a merged section, the SH_INFO value is the size (in bytes) of the objects to
be merged. Such sections should not be writable.
b Local (SHF_MIPS_LOCAL) sections are for multi-process programs sharing
an address space. They must be copied for each process which attempts to write
to them. This copying does not occur until after the second process is spawned, so
that the initial process can perform dynamic initialization common to all pro-
cesses’ copies of the section. This attribute replaces the predefined COFF lcldta
and .lbss sections.
c SHF_MIPS_LOCAL and SHF_MIPS_GPREL are mutually exclusive, i.e. a
local data section may not be placed in the short gp-relative data area.
A number of special sections are predefined, with standard names and at-
tributes. Note, however, that an ELF producer may create arbitrary sec-
tions with arbitrary names and attributes, and may generate the
predefined sections with additional attributes. For example, executable
code may be generated in multiple sections with arbitrary names, not just
in .text.
Table 10 Special Sections
Name Type Default Attributes
.bss SHT_NOBITS SHF_ALLOC + SHF_WRITEPage 16 007-4658-001
Table 10 Special Sections
Name Type Default Attributes
.comment SHT_PROGBITS none (by default)
.data SHT_PROGBITS SHF_ALLOC + SHF_WRITE
.data1 SHT_PROGBITS (gABI, not used by MIPS)
.debug SHT_PROGBITS (gABI, not used by MIPS)
.dynamic SHT_DYNAMIC SHF_ALLOC a
.dynstr SHT_STRTAB SHF_ALLOC
.dynsym SHT_DYNSYM SHF_ALLOC
.fini SHT_PROGBITS SHF_ALLOC + SHF_EXECINSTR
.got SHT_PROGBITS SHF_ALLOC + SHF_WRITE +
SHF_MIPS_GPREL
.hash SHT_HASH SHF_ALLOC
.init SHT_PROGBITS SHF_ALLOC + SHF_EXECINSTR
.interp SHT_PROGBITS SHF_ALLOC
.line SHT_PROGBITS SHF_ALLOC
.note SHT_NOTE none (by default)
.plt SHT_PROGBITS (gABI, not used by MIPS)
.relname SHT_REL none (by default), see [ABI32]
.relaname SHT_RELA none (by default), see [ABI32]
.rodata SHT_PROGBITS SHF_ALLOC
.rodata1 SHT_PROGBITS (gABI, not used by MIPS)
.shstrtab SHT_STRTAB (gABI, not used by MIPS)
.strtab SHT_STRTAB none
.symtab SHT_SYMTAB none
.text SHT_PROGBITS SHF_ALLOC + SHF_EXECINSTR
.MIPS.Addrs SHT_MIPS_PIXIE none
.MIPS.Binmap SHT_MIPS_PIXIE none
.MIPS.compact_rel SHT_MIPS_COMPACT none
c
.conflict SHT_MIPS_CONFLICT SHF_ALLOC
.MIPS.contentname SHT_MIPS_CONTENT SHF_ALLOC+ SHF_MIPS_NOSTRIP
.debug_abbrev SHT_MIPS_DWARF none (generic DWARF section)007-4658-001 ELF-64 Object File Format Page 17
Table 10 Special Sections
Name Type Default Attributes
.debug_aranges SHT_MIPS_DWARF none (generic DWARF section)
.debug_frame SHT_MIPS_DWARF SHF_MIPS_NOSTRIP
(generic DWARF section)
.debug_funcnames SHT_MIPS_DWARF none (generic DWARF section)
.debug_info SHT_MIPS_DWARF none (generic DWARF section)
.debug_line SHT_MIPS_DWARF none (generic DWARF section)
.debug_loc SHT_MIPS_DWARF none (generic DWARF section)
.debug_pubnames SHT_MIPS_DWARF none (generic DWARF section)
.debug_str SHT_MIPS_DWARF none (generic DWARF section)
.debug_typenames SHT_MIPS_DWARF none (MIPS DWARF section)
.debug_varnames SHT_MIPS_DWARF none (MIPS DWARF section)
.debug_weaknames SHT_MIPS_DWARF none (MIPS DWARF section)
.dynamic SHT_DYNAMIC SHF_ALLOC
.MIPS.eventsname SHT_MIPS_EVENTS SHF_ALLOC+SHF_MIPS_NOSTRIP
.gptabname b SHT_MIPS_GPTAB none
.MIPS.Graph SHT_MIPS_PIXIE none
.MIPS.interfaces SHT_MIPS_IFACE SHF_ALLOC+SHF_MIPS_NOSTRIP
.MIPS.lbss SHT_NOBITS SHF_ALLOC + SHF_WRITE +
.MIPS.ldata SHT_PROGBITS SHF_MIPS_LOCAL d
.lib obsolete
.liblist c SHT_MIPS_LIBLIST SHF_ALLOC
.lit4 b SHT_PROGBITS SHF_ALLOC + SHF_MIPS_MERGE
+ SHF_MIPS_GPREL a
.lit8 b SHT_PROGBITS SHF_ALLOC + SHF_MIPS_MERGE
+ SHF_MIPS_GPREL a
.MIPS.lit16 b SHT_PROGBITS SHF_ALLOC + SHF_MIPS_MERGE
+ SHF_MIPS_GPREL a
.MIPS.Log SHT_MIPS_PIXIE none
.MIPS.Map SHT_MIPS_PIXIE none
.mdebug obsolete to be replaced by DWARF sections
.MIPS.options SHT_MIPS_OPTIONS SHF_ALLOC+SHF_MIPS_NOSTRIPPage 18 007-4658-001
Table 10 Special Sections
Name Type Default Attributes
.msym SHT_MIPS_MSYM SHF_ALLOC
.MIPS.Graph SHT_MIPS_PIXIE none
.MIPS.Perf_argtrace SHT_MIPS_PIXIE none
.MIPS.Perf_bb_offsets SHT_MIPS_PIXIE none
.MIPS.Perf_call_graph SHT_MIPS_PIXIE none
.MIPS.Perf_function SHT_MIPS_PIXIE none
.MIPS.Perf_table SHT_MIPS_PIXIE none
.MIPS.Perf_weak_names SHT_MIPS_PIXIE none
.rel.dyn SHT_REL SHF_ALLOC
.reldname SHT_RELA SHF_ALLOC
b
.sbss SHT_NOBITS SHF_ALLOC + SHF_MIPS_GPREL +
SHF_WRITE
.sdata b SHT_PROGBITS SHF_ALLOC + SHF_MIPS_GPREL +
SHF_WRITE
.srdata b SHT_PROGBITS SHF_ALLOC + SHF_MIPS_GPREL
.MIPS.symlib SHT_MIPS_SYMBOL_LIB SHF_ALLOC
.MIPS.translate SHT_PROGBITS SHF_MIPS_NOSTRIP
+ SHF_ALLOC (non-shared only)
.ucode SHT_MIPS_UCODE none (obsolete)
a [ABI32M] specifies these sections with SHF_WRITE as well. Why?
b A MIPS ABI-64 compiliant system must support these sections.
c
A MIPS ABI-64 compliant system must recognize, but may choose to ignore, these sections. Howev-
er, if either is supported, both must be.
d The .lbss and lcldata sections can be replaced with arbitrary sections having the
SHF_MIPS_LOCAL attribute; they will no longer be recognized by the system strictly based on
name.
We expect more use of non-predefined sections in the future to achieve
Linker
Processing greater control over process memory allocation. The linker is expected to
combine sections with matching name and attributes, then groupings
with matching attributes, and finally groupings with consistent attributes
(e.g. all SHT_MIPS_GPREL sections, or all read-only sections). The pre-
cise rules will be defined in Section 3.007-4658-001 ELF-64 Object File Format Page 19
2.4 String Table
This section type is unchanged from [ABI32]. A String Table section has
the following attributes:
name .strtab
sh_type SHT_STRTAB
sh_link SHN_UNDEF
sh_info 0
sh_flags SHF_ALLOC
requirements see .symtab
2.5 Symbol Table
A symbol table section is unchanged from [ABI32] except for the types
of some of its fields.
A symbol table section and its associated string table section must be
present for any executable file with DSO dependencies, or for any DSO.
It is permissible to remove from it symbols resolved within itself if they
are not preemptible (protected) and not visible outside this object. (All
defined symbols in an executable file are protected, but symbols must
have been explicitly declared protected in a DSO, and hidden in either a
DSO or an executable. See the discussion associated with Table 14 for
definitions of these terms.)
A Symbol Table section has the following attributes:
name .symtab
sh_type SHT_SYMTAB
sh_link Section header index of the associated string table
sh_info 0
sh_flags SHF_ALLOC
requirements see discussion above
The structure of a symbol table item is given by Table 11 below.Page 20 007-4658-001
Table 11 ELF-64 Symbol Table Structure
Name Type Comments
st_name Elf64_Word Name’s index into string table
st_info Elf64_Byte Symbol type and binding: see
Table 12 and Table 13
st_other Elf64_Byte Other info: see Table 14
st_shndx Elf64_Section Index of section where defined
st_value Elf64_Addr Symbol value
st_size Elf64_Xword Symbol size
The high-order nibble of the st_info field specifies the symbol’s binding
(see Table 12), and the low-order nibble specifies its type (see Table 13).
Table 12 Symbol Binding (ELF32_ST_BIND)
Constant Name Value Comments
STB_LOCAL 0 Not visible outside object file where defined
STB_GLOBAL 1 Visible to all object files. Multiple defini-
tions cause errors. Force extraction of defin-
ing object from archive file.
STB_WEAK 2 Visible to all object files. Ignored if
STB_GLOBAL with same name found. Do
not force extraction of defining object from
archive file. Value is 0 if undefined.
STB_LOPROC 13 First processor-specific binding
STB_SPLIT_COMMON 13 Split common symbol. See Section 2.5.1.
STB_HIPROC 15 Last processor-specific binding007-4658-001 ELF-64 Object File Format Page 21
Table 13 Symbol Type (ELF32_ST_TYPE)
Constant Name Value Comments
STT_NOTYPE 0 Not specified
STT_OBJECT 1 Data object: variable, array, etc.
STT_FUNC 2 Function or other executable code
STT_SECTION 3 Section. Exists primarily for relocation
STT_FILE 4 Name (pathname?) of the source file associated
with object. Binding is STT_LOCAL, section
index is SHN_ABS, and it precedes other
STB_LOCAL symbols if present
STT_LOPROC 13 First processor-specific type
STT_HIPROC 15 Last processor-specific type
The binding type of a symbol is used to control its visibility, as well as
resolution in the case of multiple definitions, between the relocatable ob-
jects comprising a program. This semantics is extended to interfaces be-
tween an executable and/or DSOs unchanged — it is simply interpreted
by the dynamic linker instead of the static linker. In order to allow inde-
pendent control of interfaces between executable and DSOs without af-
fecting the binding type semantics within them, information in the
st_other field, as given in Table 14 below, is used to specify visibility and
accessibility of symbols outside the containing executable/DSO, which
we term the symbol export class.
● By default, global, weak, or common symbols are preemptible, i.e.
they may be preempted by definitions of the same name elsewhere.
● Symbols defined in the current component are protected if they are
visible outside but not preemptible, meaning that any reference to
such a symbol from within the defining executable or DSO must
resolve to the local definition even if there are definitions in other
executables or DSOs which would normally preempt it.
● Symbols defined in the current component are hidden if their
names are not visible outside — such symbols are necessarily pro-
tected, and this attribute may be used to control the external inter-
face of a DSO, but such objects may still be referenced from
outside if an address is passed outside as a pointer.Page 22 007-4658-001
● Symbols are internal if their addresses are not passed outside, e.g.
static C functions whose address is never taken.
The visibility semantics of these attributes also allow various optimiza-
tions. Whereas care must be taken to maintain position-independence and
proper GOT usage for references to and definitions of symbols which
might be preempted by or referenced from other DSOs, these restrictions
all allow references from the same executable/DSO to make stricter as-
sumptions about the definitions. References to protected symbols (and
hence to hidden or internal symbols) may be optimized by using absolute
addresses in executables or by assuming addresses to be relatively near-
by. Internal functions do not normally require gp establishment code be-
cause they will always be entered from the same executable/DSO with
the correct gp already set up.
None of these attributes affects resolution of symbols within an execut-
Linker
Processing able or DSO during static linking — such resolution is controlled by the
binding type. (However, if the static linker references symbol definitions
in other DSOs during link time, it is constrained by their export classes.)
Once the static linker has chosen its resolution, these attributes impose
two requirements, both based on the fact that various references in the
code being linked may have been optimized to take advantage of the at-
tributes. First, all of these attributes imply that a symbol must be defined
in the current DSO/executable. If a symbol with one of these attributes
has no definition within the executable/DSO being linked, then it must be
resolved to allocated space if common, resolved to zero if weak, or an er-
ror reported otherwise. Second, if any reference to, or definition of, a
name is a symbol with one of these attributes, the attribute must be prop-
agated to the resolving symbol in the linked object.
Table 14 st_other Field Masks
Constant Name Value Comments
STO_EXPORT 3 DSO export class — one of:
STO_DEFAULT 0 Default: STB_GLOBAL or
STB_WEAK are preemptible,
STB_LOCAL are hidden.
STO_INTERNAL 1 Not referenced outside executable/DSO
STO_HIDDEN 2 Not visible outside executable/DSO
STO_PROTECTED 3 Not preemptible007-4658-001 ELF-64 Object File Format Page 23
Table 14 st_other Field Masks
Constant Name Value Comments
STO_OPTIONAL 4 Symbol is optional. If no definition is
available at runtime, it is resolved to the
symbol _RLD_MISSING.
Normally in relocatable files, a symbol’s value refers to its offset within
the section specified by the st_shndx field. Its value will therefore be ad-
justed as the section moves during relocation. Certain special section in-
dex values imply other semantics, as described in Table 15:
Resolution rules for optional symbols (STO_OPTIONAL) are as follows.
The static linker (ld) should convert a reference to an optional definition
Linker
Processing (i.e. in another DSO) to an optional reference. The merge of an optional
and a non-optional reference becomes optional. The optional type is ig-
nored for SHN_COMMON and SHN_ACOMMON symbols, and does not af-
fect stub generation and resolution. In the runtime linker (rld), unresolved
optional symbols are silently resolved to the reserved symbol
_RLD_MISSING, defined in libc.so.1. Optional references do not trigger
the loading of delay-loaded libraries. Therefore, optional references may
go unresolved until some other event triggers the loading of the de-
lay-loaded library, and one may not check the availability of an optional
feature found in a delay-loaded library until some other event has forced
the library to be loaded.
Table 15 st_shndx Field Special Values
Name Value Semantics
The symbol is undefined. Its value will be determined by its appearance
SHN_UNDEF 0
as a defined symbol in another object file.
Section indices between SHN_LORESERVE and
SHN_LORESERVE 0xff00 SHN_HIRESERVE are reserved for special values — they do not re-
fer to the section header table.
Section indices between SHN_LOPROC and SHN_HIPROC are re-
SHN_LOPROC 0xff00
served for processor-specific values.
SHN_MIPS_ACOMMON 0xff00 Allocated common symbols in a DSOa,e.
SHN_MIPS_TEXT 0xff01 Reserved (obsolete).Page 24 007-4658-001
Table 15 st_shndx Field Special Values
Name Value Semantics
SHN_MIPS_DATA 0xff02 Reserved (obsolete).
SHN_MIPS_SCOMMON 0xff03 gp-addressable common symbolsb (relocatable objects only).
SHN_MIPS_SUNDEFINED 0xff04 gp-addressable undefined symbolsc (relocatable objects only).
Local common, equivalent to SHN_COMMON, except that the com-
mon block will be allocated in a local section, i.e. one replicated for
SHN_MIPS_LCOMMON 0xff05
each process in a multi-process program sharing memory (see
SHF_MIPS_LOCAL in Section 2.3).d,e
Local undefined symbol, equivalent to SHN_UNDEFINED, except
that the symbol must resolve to a local section, i.e. one replicated for
SHN_MIPS_LUNDEFINED 0xff06
each process in a multi-process program sharing memory (see
SHF_MIPS_LOCAL in Section 2.3).d
Section indices between SHN_LOPROC and SHN_HIPROC are re-
SHN_HIPROC 0xff1f
served for processor-specific values.
SHN_ABS 0xfff1 The symbol’s value is absolute and does not change due to relocation.
The symbol labels a common block which has not yet been allocateda.
SHN_COMMON 0xfff2 Its st_value specifies alignment, similar to a section header’s
sh_addralign field. Its size is the number of bytes required.
Section indices between SHN_LORESERVE and
SHN_HIRESERVE 0xffff SHN_HIRESERVE are reserved for special values — they do not re-
fer to the section header table.
a Normal SHN_COMMON symbols are not allocated in DSOs, which means that if they are not allocated else-
where (in the main executable or another DSO), rld must allocate them at runtime. SHN_MIPS_ACOMMON
symbols are used in DSOs to mark common that has been allocated in advance to avoid runtime allocation, but still
have common semantics, i.e. are not initialized and may be preempted by non-common definitions from any DSO.
The st_value of such a symbol is its virtual address. It may be relocated, but the alignment of its address must be
preserved up to modulo 65,536.
b SHN_MIPS_SCOMMON symbols are common symbols which must be allocated within 32,768 bytes of gp.
c SHN_MIPS_SUNDEFINED symbols are undefined symbols which must be resolved to addresses within 32,768
bytes of gp.
d SHN_MIPS_LCOMMON and SHN_MIPS_LUNDEFINED symbols must be consistently defined in a program,
i.e. every appearance of the symbol must be either an undefined SHN_MIPS_LCOMMON reference, a
SHN_MIPS_LUNDEFINED reference, or a definition in a SHF_MIPS_LOCAL section. These symbols may
not be gp-relative.
e SHN_MIPS_ACOMMON symbols with values (virtual addresses) in SHF_MIPS_LOCAL sections are equiva-
lent to SHN_MIPS_LCOMMON symbols, except that they are pre-allocated by the static linker.
In executable and shared object files, the symbol’s value is a virtual ad-
dress (if defined), and the section header index is irrelevant. If the section007-4658-001 ELF-64 Object File Format Page 25
header index of a function symbol is SHN_UNDEF and the st_value is
non-zero, it is the virtual address of a stub for lazy evaluation of a symbol
defined in one of the associated DSOs.
ELF-32: The extension of using st_other for specifying DSO-related
ELF-32
scope attributes is used in ELF-32 beginning with the IRIX 5.1 release
for linker-generated symbols which must be protected. As this field is
currently unused, there should be no compatibility issues unless there are
tools which attempt to enforce non-use. Tools which ignore this field will
be unable to cope with the implied symbol resolution.
2.5.1 Split Common Symbols
It is sometimes desirable for the compiler to split a Fortran COMMON
block into multiple pieces for separate allocation (e.g. to control relative
position in the processor cache). The MIPSpro compilers do so under ap-
propriate options, and represent the resulting decomposition as described
below. The static linker (ld) then determines whether the decomposition
is safe, and reassembles the COMMON if not.
A split common symbol is represented in a relocatable object by a normal
symbol for the original COMMON block, plus a split common symbol
for each element of the decomposition. The split common symbol inher-
its alignment, binding type, export class, and section index field informa-
tion from the parent common, allowing its symbol table entry to be
redefined as given by the modified version of Table 11 in Table 16 below:
Table 16 ELF-64 Split Common Component Symbol Table Element
Name Type Comments
st_name Elf64_Word Component name’s index into string table
st_info Elf64_Byte STB_SPLIT_COMMON
st_other Elf64_Byte STO_SC_ALIGN_UNUSED
st_shndx Elf64_Section Symbol index of parent common symbol
st_value Elf64_Addr Offset of component from base of parent
common symbol
st_size Elf64_Xword Component sizePage 26 007-4658-001
A split common symbol is identified by the STB_SPLIT_COMMON value
of the st_info field, requiring the alternate interpretation of its other fields
given above.
Compiler Requirements:
Compiler
Processing ● The component symbols produced by the compiler must be a parti-
tion of the parent COMMON. That is, the first should start at off-
set zero, the second at offset size(first), etc., and length(parent) =
offset(last)+size(last) = sum(sizes).
● Subject to the above requirement, the compiler is allowed to split
common blocks arbitrarily, and the linker is responsible for identi-
fying problems and reassembling the original common block.
Linker Requirements:
Linker
Processing ● The linker must produce a final partition which is consistent with
each of the individual objects' partitions in the sense that each
component from an input relocatable object falls entirely within
one of the output components.
● If the linker partitions the common, it must replace the component
symbols by normal (e.g. common, bss, or data) symbols, produc-
ing an object which contains no split common component symbols
(and therefore looks like an ABI-compliant object). It may do so
either by producing a distinct regular symbol for each component,
or by replacing the component symbols by appropriate offsets
from a single symbol for the common. Similarly, if it reassembles
the common, it must remove the component symbols.
● If the linker partitions the common, the resulting symbols must not
be exported, to avoid inadvertent incorrect references if one of the
referenced DSOs is replaced later with a version which references
the name.
● The following situations require that the linker reassemble the
original common:
a. There is an explicit linker request to export the common block
symbol (implying that some DSO may contain a reference to
it with unknown assumptions).
b. The linker finds a relocation against the common block sym-
bol (implying code generated to reference the original com-
mon block with unknown assumptions).007-4658-001 ELF-64 Object File Format Page 27
c. The linker finds a reference to the common block symbol
from any DSO (implying that the DSO contains a reference to
it with unknown assumptions).
d. The common block symbol is initialized with a single
BLOCK DATA (i.e. it is defined at a specific location in a data
section).
e. The linker finds a PU or object file in which the common has
not been split (a variant of (a) and (c) ).
A linker implementation may choose to reassemble split common
blocks in other circumstances.
2.6 Hash Table
A hash table section is unchanged from [ABI32]. It has the following at-
tributes:
name .hash
sh_type SHT_HASH
sh_link Section header index of the associated symbol table
sh_info 0
sh_flags SHF_ALLOC
requirements may not be stripped
See [ABI32] for a description of the hash table structure and hash func-
tion, which are unchanged.
2.7 Register Information Section
This section is strictly a 32-bit ABI section, which specifies the register
usage of the code in an object file. In 64-bit ELF, this section is obsolete,
and is superceded by the Options Section described in Section 2.8 below.
Its section attributes are:
name .reginfo
sh_type SHT_MIPS_REGINFO
sh_link SHN_UNDEF
sh_info 0
sh_flags nonePage 28 007-4658-001
requirements obsolete — not strippable if present in ELF-32 file
The structure of a Register Information descriptor is given by Table 19 in
Section 2.8 below.
ELF-32: MIPS tools will ignore this section in 32-bit ELF if a .MIPS.op-
ELF-32
tions section is present.
2.8 Options Section
This section specifies miscellaneous options to be applied to an object
file. An options section is required, and must contain at least an
ODK_REGINFO descriptor (below). In a shared executable or DSO, the
options section should immediately follow the program header table for
best startup performance, and the .dynamic section must contain a
DT_MIPS_OPTIONS tag pointing to it. In a non-shared program (which is
not ABI-conformant), the options section must immediately follow the
program header table.
Its section attributes are:
name .MIPS.options
sh_type SHT_MIPS_OPTIONS
sh_link SHN_UNDEF
sh_info 0
sh_flags SHF_ALLOC + SHF_MIPS_NOSTRIP
requirements mandatory, may not be stripped
An options record consists of a sequence of variable length (and variable
format) descriptors, which may apply either to the entire object file or to
a specific section. Each such descriptor begins with the following header:
Table 17 Options Descriptor Header (Elf_Options)
Field Name Type Comments
kind Elf64_Byte Determines interpretation of variable part of
descriptor — see Table 18 below007-4658-001 ELF-64 Object File Format Page 29
Table 17 Options Descriptor Header (Elf_Options)
Field Name Type Comments
size Elf64_Byte Byte size of descriptor, including this header a
section Elf64_Section Section header index of section affected, or 0
for global options
info Elf64_Word Kind-specific information
a
Descriptors may have arbitrary size (up to 255 bytes). However, they must be
8-byte aligned, and must be null padded if the given size is not 0 mod 8.
The Options Descriptor kinds are given in Table 18 below. The various
descriptors associated with them follow. For each descriptor kind, the as-
sociated table gives the value of the size field, the usage of the info field,
and any additional fields required.
Table 18 Options Descriptor Kinds
Constant Name Value Comments
ODK_NULL 0 Undefined
ODK_REGINFO 1 Register usage information
ODK_EXCEPTIONS 2 Exception processing options
ODK_PAD 3 Section padding options
ODK_HWPATCH 4 Hardware patches applied
ODK_FILL 5 Linker fill value
ODK_TAGS 6 Space for tool identification
ODK_HWAND 7 Hardware AND patches applied
ODK_HWOR 8 Hardware OR patches applied
ODK_GP_GROUP 9 GP group to use for text/data sections
ODK_IDENT 10 ID information
ODK_PAGESIZE 11 Page size information
The .MIPS.options section replaced .reginfo in ELF-32 with the MIPSpro
6.0 compilers, although it remains in use in the 5.x (ucode) compilers.Page 30 007-4658-001
2.8.1 Register Information Option Descriptor
The ODK_REGINFO descriptor supercedes what used to be in the special
.reginfo section. The structure of a Register Information descriptor is giv-
en by Table 19 below.
Table 19 Register Information Structure
Field Name Type Comments
kind Elf64_Byte value is ODK_REGINFO
size Elf64_Byte value is 40
section Elf64_Section 0
info Elf64_Word unused
ri_gprmask Elf64_Word Mask of general registers used
ri_pad Elf64_Word Unused padding field (for align-
ment of following fields -- ELF64
only)
ri_cprmask[4] Elf64_Word[4] Mask of coprocessor registers used
ri_gp_value Elf64_Addr Initial value of gp a
a If there is no register information descriptor, the initial value of gp is assumed to
be 0. The significance of this value is that, for any SHT_MIPS_GPREL sec-
tion, if its start address (as given by the section’s sh_addr) is specified as x
(which will usually be zero), then gp is assumed to be initialized to its relocated
start address plus (ri_gp_value-x). The initial addends of any
R_MIPS_GPREL-relocated values will be correct offsets if the section is not
moved relative to gp.
ELF-32: ELF-32 does not have the ri_pad field. We use this section in-
ELF-32
stead of .reginfo beginning with IRIX 6.0, since we require the additional
descriptors described below. However, .reginfo may still be generated for
the benefit of foreign (and back-rev) tools.
2.8.2 Exception Information Option Descriptor
The ODK_EXCEPTIONS descriptor contains information only in the info
field of the basic options descriptor header, as given by the masks in Ta-
ble 20 below. Its size is 8 bytes.007-4658-001 ELF-64 Object File Format Page 31
Table 20 Exception Information info Field Masks
Mask Name Value Comments
OEX_FPU_MIN 0x0000001f Min FPU exception enable a
OEX_FPU_MAX 0x00001f00 Max FPU exception enable a
OEX_PAGE0 0x00010000 Page zero of the virtual address space
must be mapped b
OEX_SMM 0x00020000 Run in sequential memory mode c
OEX_PRECISEFP 0x00040000 Run in precise FP exception mode d
OEX_DISMISS 0x00080000 Dismiss invalid address traps e
a These masks bound the setting of the FPU exception enable masks at runtime.
The runtime mask may enable only bits in the maximum mask, and must enable
bits in the minimum mask. See discussion below.
b If set, loads from page zero of the virtual address space must not cause invalid
address faults. However, page zero may be write-protected. "Page zero" here
implies the minimum, given by ELF_MIPS_MINPGSZ in elf.h.
c If set, and the process is running on an R8000 or other processor with a sequen-
tial memory mode, execute in that mode.
d If set, and the process is running on an R8000 or other processor with a distinct
mode for precise floating point exceptions, execute in that mode.
e If set, any invalid address traps encountered should be dismissed without abort-
ing or otherwise notifying the running process.
Linkage and Execution: The static linker (ld) must combine the
Linker
Processing descriptors from all object files linked as follows. The OEX_FPU_MIN
fields are OR’ed together, so that any exception enable required by any of
the objects will be set for the process. Similarly, the OEX_FPU_MAX
fields are AND’ed together, so that any exception required to be
suppressed by any of the objects will be suppressed for the process. The
OEX_PAGE0, OEX_SMM, OEX_PRECISEFP, and OEX_DISMISS flags are
OR’ed together. The linker should always produce an ODK_EXCEPTIONS
descriptor even if none of the linked objects contained one, so that simple
tools can be used to manipulate these options. In such a case, the info field
should contain the value OEX_FPU_MAX, i.e. any FP exceptions allowed,
and no other options set.
At execution time, the dynamic linker (rld) must perform a similar task to
combine the descriptors from the main executable and any DSOs, and it
must perform the appropriate actions to achieve the implied statePage 32 007-4658-001
(typically making calls to the kernel). In addition, it must retain the
implied state for reference — in the event that a dlopen call is made to
open a new DSO, its state must be checked for compatibility with the
current state, and that state adjusted as required. The runtime linker is not
required to back out the requirements of a DSO which is subsequently
removed from the process image via dlclose.
For a non-shared program, the kernel or the runtime system (e.g. crt0)
must perform the same task, setting the implied initial state in the running
process.
Both the static and dynamic linkers should report incompatible
requirements of their components, i.e. an exception enable bit which is
set in the minimum mask and unset in the maximum mask, as errors. The
runtime system is not required to enforce retention of the specified modes
in the face of explicit attempts to set them by the running process, but it
may do so.
ELF-32: MIPS generates and uses this descriptor beginning with IRIX
ELF-32
6.0. It may be necessary to suppress it for pure-ABI objects.
2.8.3 Section Padding Option Descriptor
The ODK_PAD descriptor specifies padding required for the referenced
data section. The linker must provide for at least the indicated number of
bytes preceding or following the data section to be valid parts of the
virtual address space, guaranteed not to cause invalid address faults. This
facility is intended to allow the code generator to produce memory
references which may be beyond the referenced data object (e.g. for
software pipelining), with the assurance that they will not cause memory
faults at runtime.
If the writable flags are not set, the linker may provide padding simply by
arranging for other data sections to be contiguous to the section specified,
those other data sections need not be writable. If the writable flags are
set, writable empty space must be provided. If padding must be applied to
a symbol (e.g. because it is undefined or COMMON, and its ultimate sec-
tion is unknown), the 16-bit section is a symbol table section, and the
pad_symindex field specifies a 32-bit symbol index. In this case, since the
symbol may be allocated by another object file in the midst of a larger
section, the writable flags may not be set.
The format of this descriptor is given in Table 21 below:007-4658-001 ELF-64 Object File Format Page 33
Table 21 Section Padding Descriptor
Field Name Type Comments
kind Elf64_Byte value is ODK_PAD
size Elf64_Byte value is 16
section Elf64_Section Section to be padded a
info & 0x0001 mask Prefix writable (OPAD_PREFIX)
info & 0x0002 mask Postfix writable (OPAD_POSTFIX)
info & 0x0004 mask Pad symbol b (OPAD_SYMBOL)
pad_prefix_size Elf64_Half Size (bytes) of prefix required
pad_postfix_size Elf64_Half Size (bytes) of postfix required
pad_symindex Elf64_Word Symbol index if OPAD_SYMBOL is set
a The section field normally references a data section to be padded or, if
OPAD_SYMBOL is set, a symbol table section in which to find a symbol to be
padded. If it is zero, the descriptor applies to all data sections, and the writable
flags may not be set in this case.
b If this flag is set, the section field is a symbol table section, and the
pad_symindex field specifies a 32-bit symbol index instead of a section for
padding (generally undefined or COMMON). The writable flags may not be set
in this case.
ELF-32: We generate and use this descriptor beginning with IRIX 6.0. It
ELF-32
may be necessary to suppress it for pure-ABI objects.
Linkage: It is technically possible for the static linker (ld) to postpone
Linker
Processing processing of padding information (e.g. for symbols and/or sections
allocated at the beginning or end of a segment, or for unallocated
COMMON symbols), leaving the dynamic linker (rld) to process residual
padding descriptors. However, the MIPSpro static linker currently
processes padding completely, dealing with unallocated COMMON
symbols by turning them into ACOMMON symbols with proper
padding, and the MIPSpro dynamic linker does not deal with padding.
2.8.4 Hardware Patch Option Descriptor
The ODK_HWPATCH descriptor contains flags indicating whether various
patches required for specific hardware platforms have been applied to the
executable or DSO. It contains information only in the info field of the ba-Page 34 007-4658-001
sic options descriptor header, as given by the masks in Table 22 below. Its
size is 8 bytes. This descriptor is required in all object files, to allow sim-
ple post-generation patching.
Table 22 Hardware Patch Options Descriptor
Mask Name Value Comments
OHW_R4KEOP 0x00000001 Patch for R4000 branch at end-of-page bug
OHW_R8KPFETCH 0x00000002 Object contains prefetch instructions which
may cause R8000 prefetch bug to occur
OHW_R5KEOP 0x00000004 Patch for R5000 branch at end-of-page bug
OHW_R5KCVTL 0x00000008 R5000 cvt.[ds].l bug: clean=1
OHW_R10KLDL 0x00000010 Requires patch for R10000 misaligned load.
The static linker must merge (inclusive OR) the OHW_R8KPFETCH flags
Linker
Processing from each of the objects it links. The OHW_R4KEOPR5000 cvt.[ds].l bug.
clean=1 and OHW_R5KEOP flags are added by tools after linking.
2.8.5 Hardware AND/OR Patch Option Descriptors
The ODK_HWAND / ODK_HWOR descriptors, like ODK_HWPATCH, con-
tain flags indicating whether various patches required for specific hard-
ware platforms have been applied to the object file. They contain
information in the info field of the basic options descriptor header, plus
the following 8 bytes. Their size is 16 bytes. These descriptors are re-
quired in all object files, to allow simple post-generation patching. The
descriptor layout is given in Table 23 below.
Table 23 Hardware AND/OR Patch Option Descriptor Structure
Field Name Type Comments
kind Elf64_Byte value ODK_HWAND or ODK_HWOR
size Elf64_Byte value is 16
section Elf64_Section 0
info Elf64_Word 32 flags: see Table 24007-4658-001 ELF-64 Object File Format Page 35
Table 23 Hardware AND/OR Patch Option Descriptor Structure
Field Name Type Comments
hwp_flags1 Elf64_Word 32 flags: see Table 24
hwp_flags2 Elf64_Word 32 flags: see Table 24
Table 24 Hardware Patch AND/OR Options Descriptor Flags
Mask Name Value Comments
ODK_HWAND info masks:
OHWA0_R4KEOP_CHECKED 0x00000001 Object checked for R4K end-of-page bug.
OHWA0_R4KEOP_CLEAN 0x00000002 Object verified clean of R4K end-of-page bug.
ODK_HWAND hwp_flags1 masks:
OHWA1_... 0x???????? None yet defined.
ODK_HWAND hwp_flags2 masks:
OHWA2_... 0x???????? None yet defined.
ODK_HWOR info masks:
OHWO0_FIXADE 0x00000001 Object requires call to fixade
ODK_HWOR hwp_flags1 masks:
OHWO1_... 0x???????? None yet defined.
ODK_HWAND hwp_flags2 masks:
OHWO2_... 0x???????? None yet defined.
The static linker must merge the ODK_HWAND (bitwise AND) and
Linker
Processing ODK_HWOR (bitwise inclusive OR) flags from each of the objects it links.
Generating tools should initialize the flags to zero for fields they do not
understand, and the linker should assume that missing descriptors contain
zeroes.
2.8.6 Fill Value Option Descriptor
The ODK_FILL descriptor contains information only in the info field of the
basic options descriptor header, specifically the value used by the linker
to fill uninitialized space. Its size is 8 bytes.Page 36 007-4658-001
2.8.7 Tags Option Descriptor
The ODK_TAGS descriptor initially contains only zero-filled space (40
bytes). It is reserved for tools to identify processing that has occurred. Its
size is 48 bytes.
Table 25 Tags Option Descriptor
Field Name Type Comments
kind Elf64_Byte value is ODK_TAGS
size Elf64_Byte value is 48
section Elf64_Section 0 (unused)
info mask 0 (unused)
tags Elf64_Byte[40] initially 0. Bytes currently reserved:
0..4 (Desktop)
32..39 (other vendors)
The purpose of this descriptor is to allow tools to mark the object (exe-
cutable or DSO) without substantially rewriting the file, as would be re-
quired to add a new descriptor or section. Space in this descriptor should
be allocated very carefully, preferably a byte at a time. The .note section
is more appropriate if more space is required. The intent is that this allo-
cation last essentially forever. Although expansion is theoretically possi-
ble, doing so would eliminate its benefit for files created before the
expansion.
The last 8 bytes of the tags field are reserved for vendor-specific use by
non-MIPS/SGI vendors. Note, however, that such usage may conflict
with other vendors’ usage, and should therefore be limited to files which
is not expected to be handled by other vendors’ software.You can also read
