Sections

An object file's section header table lets onelocate all the file's sections.The section header table is an array of Elf32_Shdr or Elf64_Shdr structuresas described below.A section header table index is a subscript into this array.The ELF header's e_shoffmember gives the byte offset from the beginning of thefile to the section header table.e_shnum normally tells how many entries the section header table contains.e_shentsize gives the size in bytes of each entry.

If the number of sections is greater than or equal toSHN_LORESERVE (0xff00), e_shnumhas the value SHN_UNDEF (0) and theactual number of section header tableentries is contained in the sh_size field ofthe section header at index 0(otherwise, the sh_size member of the initial entry contains 0).

Some section header table indexes are reserved in contextswhere index size is restricted, for example, the st_shndxmember of a symbol table entry and the e_shnum ande_shstrndx members of the ELF header.In such contexts, the reserved values do not represent actualsections in the object file. Also in such contexts, an escape value indicates that the actual sectionindex is to be found elsewhere, in a larger field.

Figure 4-7: Special Section IndexesNameValue

SHN_UNDEF0

SHN_LORESERVE0xff00

SHN_LOPROC0xff00

SHN_HIPROC0xff1f

SHN_LOOS0xff20

SHN_HIOS0xff3f

SHN_ABS0xfff1

SHN_COMMON0xfff2

SHN_XINDEX0xffff

SHN_HIRESERVE0xffff

SHN_UNDEF

This value marks an undefined, missing, irrelevant, orotherwise meaningless section reference.For example, a symbol ``defined'' relative to section numberSHN_UNDEF is an undefined symbol.

Although index 0 is reserved as the undefined value,the section header table contains an entry for index 0.If the e_shnummember of the ELF header says a file has 6 entriesin the section header table, they have the indexes 0 through 5.The contents of the initial entry are specified later in thissection.SHN_LORESERVE

This value specifies the lower bound of therange of reserved indexes.

SHN_LOPROC through SHN_HIPROC

Values in this inclusive rangeare reserved for processor-specific semantics.

SHN_LOOS through SHN_HIOS

Values in this inclusive rangeare reserved for operating system-specific semantics.

SHN_ABS

This value specifies absolute values for the corresponding reference.For example, symbols defined relative to section number SHN_ABShave absolute values and are not affected by relocation.

SHN_COMMON

Symbols defined relative to this section are common symbols,such as FORTRANCOMMONor unallocated C external variables.

SHN_XINDEX

This value is an escape value.It indicates that the actual section header index is too large to fitin the containing field and is to be found in another location(specific to the structure where it appears).

SHN_HIRESERVE

This value specifies the upper bound of therange of reserved indexes.The system reserves indexes between SHN_LORESERVEand SHN_HIRESERVE,inclusive; the values do not reference the section header table.The section header table does notcontain entries for the reserved indexes.

Sections contain all information in an object fileexcept the ELF header, the program header table,and the section header table.Moreover, object files' sections satisfy several conditions.

Every section in an object file has exactly onesection header describing it.Section headers may exist that do not have a section.

Each section occupies one contiguous (possibly empty)sequence of bytes within a file.

Sections in a file may not overlap.No byte in a file resides in more than one section.

An object file may have inactive space.The various headers and the sections might not``cover'' every byte in an object file.The contents of the inactive data are unspecified.

A section header has the following structure.Figure 4-8: Section Header

typedef struct { Elf32_Word sh_name; Elf32_Word sh_type; Elf32_Word sh_flags; Elf32_Addr sh_addr; Elf32_Off sh_offset; Elf32_Word sh_size; Elf32_Word sh_link; Elf32_Word sh_info; Elf32_Word sh_addralign; Elf32_Word sh_entsize;} Elf32_Shdr;typedef struct { Elf64_Word sh_name; Elf64_Word sh_type; Elf64_Xword sh_flags; Elf64_Addr sh_addr; Elf64_Off sh_offset; Elf64_Xword sh_size; Elf64_Word sh_link; Elf64_Word sh_info; Elf64_Xword sh_addralign; Elf64_Xword sh_entsize;} Elf64_Shdr;

sh_name

This member specifies the name of the section.Its value is an index into the section headerstring table section [see``String Table'' below],giving the location of a null-terminated string.

sh_type

This member categorizes the section's contents and semantics.Section types and their descriptions appear.

sh_flags

Sections support 1-bit flags that describe miscellaneous attributes.Flag definitions appear .

sh_addr

If the section will appear in the memory image of a process,this member gives the address at which the section's firstbyte should reside.Otherwise, the member contains 0.

sh_offset

This member's value gives the byte offset from the beginning of the fileto the first byte in the section.One section type, SHT_NOBITSdescribed,occupies no space in the file, and itssh_offset member locates the conceptual placement in the file.

sh_size

This member gives the section's size in bytes.Unless the section type isSHT_NOBITS, the section occupies sh_sizebytes in the file.A section of type SHT_NOBITSmay have a non-zero size, but it occupies no space in the file.

sh_link

This member holds a section header table index link,whose interpretation depends on the section type.A belowdescribes the values.

sh_info

This member holds extra information,whose interpretation depends on the section type.A belowdescribes the values. If the sh_flags field for thissection header includes the attribute , then this member represents a section header table index.

sh_addralign

Some sections have address alignment constraints.For example, if a section holds a doubleword,the system must ensure doubleword alignment for the entire section.The value of sh_addrmust be congruent to 0, modulo the value of sh_addralign.Currently, only 0 and positive integral powers of two are allowed.Values 0 and 1 mean the section has no alignment constraints.

sh_entsize

Some sections hold a table of fixed-size entries,such as a symbol table.For such a section, this member gives the size in bytes of each entry.The member contains 0 if the section does not hold a tableof fixed-size entries.

A section header's sh_type member specifies the section's semantics.

<="" a="">Figure 4-9: Section Types,sh_typeNameValue

SHT_NULL0

SHT_PROGBITS1

SHT_SYMTAB2

SHT_STRTAB3

SHT_RELA4

SHT_HASH5

SHT_DYNAMIC6

SHT_NOTE7

SHT_NOBITS8

SHT_REL9

SHT_SHLIB10

SHT_DYNSYM11

SHT_INIT_ARRAY14

SHT_FINI_ARRAY15

SHT_PREINIT_ARRAY16

SHT_GROUP17

SHT_SYMTAB_SHNDX18

SHT_LOOS0x60000000

SHT_HIOS0x6fffffff

SHT_LOPROC0x70000000

SHT_HIPROC0x7fffffff

SHT_LOUSER0x80000000

SHT_HIUSER0xffffffff

<="" a="">

SHT_NULL

This value marks the section header as inactive;it does not have an associated section.Other members of the section header have undefined values.

SHT_PROGBITS

The section holds information defined by the program,whose format and meaning are determined solely by the program.

SHT_SYMTAB and SHT_DYNSYM

<="" a="">These sections hold a symbol table.Currently, an object file may have only one section of each type,but this restriction may be relaxed in the future.Typically, SHT_SYMTABprovides symbols for link editing, though it may also beused for dynamic linking.As a complete symbol table, it may contain many symbols unnecessaryfor dynamic linking.Consequently, an object file may also contain a SHT_DYNSYMsection, which holds a minimal set of dynamic linking symbols,to save space.See``Symbol Table'' belowfor details.

SHT_STRTAB

The section holds a string table.An object file may have multiple string table sections.See``String Table''below for details.

SHT_RELA

The section holds relocation entrieswith explicit addends, such as typeElf32_Rela for the 32-bit class of object filesor type Elf64_Rela for the 64-bit class of object files.An object file may have multiple relocation sections.``Relocation''below for details.

SHT_HASH

The section holds a symbol hash table.Currently, an object file may have only one hash table,but this restriction may be relaxed in the future.See``Hash Table''in the Chapter 5 for details.

SHT_DYNAMIC

The section holds information for dynamic linking.Currently, an object file may have only one dynamic section,but this restriction may be relaxed in the future.See``Dynamic Section''in Chapter 5 for details.

SHT_NOTE

The section holds information that marks the file in some way.See``Note Section''in Chapter 5 for details.

SHT_NOBITS

A section of this type occupies no space in the file butotherwise resemblesSHT_PROGBITS.Although this section contains no bytes, the sh_offsetmember contains the conceptual file offset.

SHT_REL

The section holds relocation entrieswithout explicit addends, such as typeElf32_Rel for the 32-bit class of object files ortype Elf64_Rel for the 64-bit class of object files.An object file may have multiple relocation sections.See``Relocation''below for details.

SHT_SHLIB

This section type is reserved but has unspecified semantics.

SHT_INIT_ARRAY

This section contains an array of pointers to initialization functions,as described in``Initialization andTermination Functions'' in Chapter 5. Each pointer in the arrayis taken as a parameterless procedure with a void return.

SHT_FINI_ARRAY

This section contains an array of pointers to termination functions,as described in``Initialization andTermination Functions'' in Chapter 5. Each pointer in the arrayis taken as a parameterless procedure with a void return.

SHT_PREINIT_ARRAY

This section contains an array of pointers to functions that areinvoked before all other initialization functions,as described in``Initialization andTermination Functions'' in Chapter 5. Each pointer in the arrayis taken as a parameterless procedure with a void return.

SHT_GROUP

This section defines a section group. A section groupis a set of sections that are related and that must be treatedspecially by the linker (see for furtherdetails). Sections of type SHT_GROUP may appear onlyin relocatable objects (objects with the ELF header e_typemember set to ET_REL). The section header table entryfor a group section must appear in the section header tablebefore the entries for any of the sections that are members ofthe group.

SHT_SYMTAB_SHNDX

This section is associated with a symbol table section and is required if any of the section header indexes referencedby that symbol table contain the escape value SHN_XINDEX.The section is an array of Elf32_Word values.Each value corresponds one to one with a symbol table entryand appear in the same order as those entries.The values represent the section header indexes against whichthe symbol table entries are defined.Only if the corresponding symbol table entry's st_shndx fieldcontains the escape value SHN_XINDEXwill the matching Elf32_Word hold the actual section header index;otherwise, the entry must be SHN_UNDEF (0).

SHT_LOOS through SHT_HIOS

Values in this inclusive rangeare reserved for operating system-specific semantics.

SHT_LOPROC through SHT_HIPROC

Values in this inclusive rangeare reserved for processor-specific semantics.

SHT_LOUSER

This value specifies the lower bound of the range ofindexes reserved for application programs.

SHT_HIUSER

This value specifies the upper bound of the range ofindexes reserved for application programs.Section types between SHT_LOUSER andSHT_HIUSER may be used by the application, without conflicting withcurrent or future system-defined section types.

Other section type values are reserved.As mentioned before, the section header for index 0 (SHN_UNDEF)exists, even though the index marks undefined section references.This entry holds the following.

Figure 4-10: Section Header Table Entry:Index 0NameValueNote

sh_name0No name

sh_typeSHT_NULLInactive

sh_flags0No flags

sh_addr0No address

sh_offset0No offset

sh_sizeUnspecifiedIf non-zero, the actual number of section header entries

sh_linkUnspecifiedIf non-zero, the index of the section header string table section

sh_info0No auxiliary information

sh_addralign0No alignment

sh_entsize0No entries

A section header's sh_flagsmember holds 1-bit flags that describe the section's attributes.Defined values appear in the following table;other values are reserved.<="" a="">

<="" a="">Figure 4-11: Section Attribute FlagsNameValue

SHF_WRITE0x1

SHF_ALLOC0x2

SHF_EXECINSTR0x4

SHF_MERGE0x10

SHF_STRINGS0x20

SHF_INFO_LINK0x40

SHF_LINK_ORDER0x80

SHF_OS_NONCONFORMING0x100

SHF_GROUP0x200

SHF_TLS0x400

SHF_COMPRESSED0x800

SHF_MASKOS0x0ff00000

SHF_MASKPROC0xf0000000

If a flag bit is set in sh_flags,the attribute is ``on'' for the section.Otherwise, the attribute is ``off'' or does not apply.Undefined attributes are set to zero.

<="" a="">

SHF_WRITE

The section contains data that should be writable duringprocess execution.

SHF_ALLOC

The section occupies memory during process execution.Some control sections do not reside in the memory imageof an object file; this attribute is off for those sections.

SHF_EXECINSTR

<="" a="">The section contains executable machine instructions.

SHF_MERGE

The data in the section may be merged to eliminate duplication. Unless the SHF_STRINGS flag is also set,the data elements in the section are of a uniform size.The size of each element is specified in the section header's sh_entsize field. If the SHF_STRINGS flag is also set,the data elements consist of null-terminated character strings.The size of each character is specified in the sectionheader's sh_entsize field.

Each element in the section is compared against other elementsin sections with the same name, type and flags.Elements that would have identical values at program run-timemay be merged. Relocations referencing elements of such sections must beresolved to the merged locations of the referenced values.Note that any relocatable values, includingvalues that would result in run-time relocations, must beanalyzed to determine whether the run-time values would actuallybe identical. An ABI-conforming object file may not depend on specific elements being merged, and an ABI-conforming link editor may choose not to merge specific elements.

SHF_STRINGS

The data elements in the section consist of null-terminated characterstrings. The size of each character is specified in the section header's sh_entsize field.

SHF_INFO_LINK

The sh_info field of this section header holds a sectionheader table index.

SHF_LINK_ORDER

This flag adds special ordering requirements for link editors.The requirements apply if the sh_link field of this section's header references another section (the linked-to section). If this section is combined with othersections in the output file, it must appear in the same relative order with respect to those sections, as the linked-to sectionappears with respect to sections the linked-to section is combined with.

A typical use of this flag is to build a table that references text ordata sections in address order.

SHF_OS_NONCONFORMING

This section requires special OS-specific processing(beyond the standard )to avoid incorrect behavior.If this section has either an sh_type valueor contains sh_flags bits in the OS-specific ranges forthose fields, and a link editor processing this section does notrecognize those values, then the link editor should rejectthe object file containing this section with an error.

SHF_GROUP

This section is a member (perhaps the only one) of a section group.The section must be referenced by a section of type SHT_GROUP.The SHF_GROUP flag may be set only for sections containedin relocatable objects (objects with the ELF header e_typemember set to ET_REL).See for further details.

SHF_TLS

This section holds Thread-Local Storage,meaning that each separate execution flowhas its own distinct instance of this data.Implementations need not support this flag.

SHF_COMPRESSED

This flag identifies a section containing compressed data. SHF_COMPRESSED applies only to non-allocable sections, and cannot be used in conjunction with SHF_ALLOC. In addition, SHF_COMPRESSED cannot be applied to sections of type SHT_NOBITS.

All relocations to a compressed section specifiy offsets to the uncompressed section data. It is therefore necessary to decompress the section data before relocations can be applied. Each compressed section specifies the algorithm independently. It is permissible for different sections in a given ELF object to employ different compression algorithms.

Compressed sections begin with a compression header structure that identifies the compression algorithm.

Figure 4-12: Compression Header

typedef struct { Elf32_Word ch_type; Elf32_Word ch_size; Elf32_Word ch_addralign;} Elf32_Chdr;typedef struct { Elf64_Word ch_type; Elf64_Word ch_reserved; Elf64_Xword ch_size; Elf64_Xword ch_addralign;} Elf64_Chdr;

ch_type

This member specifies the compression algorithm. Supported algorithms and their descriptions are listed in the table below.

ch_size

This member provides the size in bytes of the uncompressed data. See sh_size.

ch_addralign

Specifies the required alignment for the uncompressed data. See sh_addralign.

The sh_size and sh_addralign fields of the section header for a compressed section reflect the requirements of the compressed section. The ch_size and ch_addralign fields in the compression header provide the corresponding values for the uncompressed data, thereby supplying the values that sh_size and sh_addralign would have had if the section had not been compressed.

The layout and interpretation of the data that follows the compression header is specific to each algorithm, and is defined below for each value of ch_type. This area may contain algorithm specific parameters and alignment padding in addition to compressed data bytes.

A compression header's ch_type member specifies the compression algoritm employed, as shown in the following table.

Figure 4-13: ELF Compression Types, ch_type

NameValue

ELFCOMPRESS_ZLIB1

ELFCOMPRESS_LOOS0x60000000

ELFCOMPRESS_HIOS0x6fffffff

ELFCOMPRESS_LOPROC0x70000000

ELFCOMPRESS_HIPROC0x7fffffff

ELFCOMPRESS_ZLIB

The section data is compressed with the ZLIB algoritm. The compressed ZLIB data bytes begin with the byte immediately following the compression header, and extend to the end of the section. Additional documentation for ZLIB may be found athttp://zlib.net.

ELFCOMPRESS_LOOS - ELFCOMPRESS_HIOS

Values in this inclusive range are reserved for operating system-specific semantics.

ELFCOMPRESS_LOPROC - ELF_COMPRESS_HIPROC

Values in this inclusive range are reserved for processor-specific semantics.

SHF_MASKOS

All bits included in this maskare reserved for operating system-specific semantics.

SHF_MASKPROC

All bits included in this maskare reserved for processor-specific semantics.If meanings are specified, the processor supplement explainsthem.

Two members in the section header,sh_link and sh_info,hold special information, depending on section type.

Figure 4-14: sh_link and sh_info Interpretationsh_typesh_linksh_info

SHT_DYNAMICThe section header index ofthe string table used byentries in the section.0

SHT_HASHThe section header index ofthe symbol table to whichthe hash table applies.0

SHT_REL

SHT_RELAThe section header index ofthe associated symbol table.The section header index ofthe section to which therelocation applies.

SHT_SYMTAB

SHT_DYNSYMThe section header index ofthe associated string table.One greater than the symbol table index of the last localsymbol (binding STB_LOCAL).

SHT_GROUPThe section header index ofthe associated symbol table.The symbol table index of an entry in theassociated symbol table. The name of the specified symbol tableentry provides a signature for the section group.

SHT_SYMTAB_SHNDXThe section header index ofthe associated symbol table section.0

Rules for Linking Unrecognized Sections

If a link editor encounters sections whose headers contain OS-specificvalues it does not recognize in the sh_typeor sh_flags fields, the link editor should combine thosesections as described below.

If the section's sh_flags bits include the attributeSHF_OS_NONCONFORMING, then the section requiresspecial knowledge to be correctly processed, and the link editor shouldreject the object containing the section with an error.

Unrecognized sections that do not have theSHF_OS_NONCONFORMING attribute, are combined in a two-phaseprocess. As the link editor combines sections using this process,it must honor the alignment constraints of the input sections (asserted by the sh_addralign field),padding between sections with zero bytes, if necessary, and producinga combination with the maximum alignment constraint of itscomponent input sections.

In the first phase, input sections that match in name, typeand attribute flags should be concatenated into single sections.The concatenation order should satisfy the requirements ofany known input section attributes (e.g, SHF_MERGEand SHF_LINK_ORDER). When not otherwise constrained,sections should be emitted in input order.

In the second phase, sections should be assigned to segments orother units based on their attribute flags. Sections of each particularunrecognized type should be assigned to the same unit unlessprevented by incompatible flags, and within a unit, sectionsof the same unrecognized type should be placed togetherif possible.

Non OS-specific processing (e.g. relocation) should be appliedto unrecognized section types. An output section header table,if present, should contain entries for unknown sections.Any unrecognized section attribute flags should be removed.

It is recommended that link editors follow the same two-phaseordering approach described above when linking sections ofknown types. Padding between such sections may have valuesdifferent from zero, where appropriate.Section Groups

Some sections occur in interrelated groups. For example, an out-of-linedefinition of an inline function might require, in addition to thesection containing its executable instructions, a read-only data section containing literals referenced, one or more debugging informationsections and other informational sections. Furthermore, there may beinternal references among these sections that would not make senseif one of the sections were removed or replaced by a duplicate fromanother object. Therefore, such groups must beincluded or omitted from the linked object as a unit.A section cannot be a member of more than one group.

A section of type SHT_GROUP defines such a groupingof sections. The name of a symbol from one of the containing object's symbol tables provides a signature for the section group.The section header of the SHT_GROUP section specifiesthe identifying symbol entry, as described above:the sh_link member contains the section header indexof the symbol table section that contains the entry. The sh_info member contains the symbol table index of the identifying entry. The sh_flagsmember of the section header contains 0. The name of the section (sh_name) is not specified.

The referenced signature symbol is not restricted.Its containing symbol table section need not be a member of the group,for example.

The section data of a SHT_GROUP section is an arrayof Elf32_Word entries. The first entry is a flag word.The remaining entries are a sequence of section header indices.

The following flags are currently defined:

Figure 4-15: Section Group FlagsNameValue

GRP_COMDAT0x1

GRP_MASKOS0x0ff00000

GRP_MASKPROC0xf0000000

GRP_COMDAT

This is a COMDAT group. It may duplicate another COMDAT groupin another object file, where duplication is defined as having thesame group signature. In such cases, only one of theduplicate groups may be retained by the linker, and themembers of the remaining groups must be discarded.

GRP_MASKOS

All bits included in this maskare reserved for operating system-specific semantics.

GRP_MASKPROC

All bits included in this maskare reserved for processor-specific semantics.If meanings are specified, the processor supplement explainsthem.

The section header indices in the SHT_GROUP sectionidentify the sections that make up the group. Each such sectionmust have the SHF_GROUP flag set in its sh_flagssection header member. If the linker decides to remove the sectiongroup, it must remove all members of the group.

This requirement is not intended to imply that special case behaviorlike removing debugging information requires removing the sectionsto which that information refers, even if they are part of the samegroup.

To facilitate removing a group without leaving dangling referencesand with only minimal processing of the symbol table, the following rules must be followed:

A symbol table entry with STB_GLOBAL or STB_WEAKbinding that is defined relative to one of a group's sections,and that is contained in a symbol table sectionthat is not part of the group,must be converted to an undefined symbol(its section index must be changed to SHN_UNDEF)if the group members are discarded.References to this symbol table entry from outside the group are allowed.

A symbol table entry with STB_LOCAL bindingthat is defined relative to one of a group's sections,and that is contained in a symbol table sectionthat is not part of the group,must be discarded if the group members are discarded.References to this symbol table entry from outside the group are not allowed.

An undefined symbol that is referenced only from one or more sectionsthat are part of a particular group,and that is contained in a symbol table sectionthat is not part of the group,is not removed when the group members are discarded.In other words,the undefined symbol is not removedeven if no references to that symbol remain.

There may not be non-symbol references to the sections comprisinga group from outside the group, for example, use of a groupmember's section header index in an sh_link orsh_info member.

Special Sections

Various sections hold program and control information.

The following tableshows sections that are used by the systemand have the indicated types and attributes.

Figure 4-16: Special SectionsNameTypeAttributes

.bss SHT_NOBITS SHF_ALLOC+SHF_WRITE

.comment SHT_PROGBITSnone

.data SHT_PROGBITSSHF_ALLOC+SHF_WRITE

.data1 SHT_PROGBITSSHF_ALLOC+SHF_WRITE

.debug SHT_PROGBITSnone

.dynamic SHT_DYNAMIC see below

.dynstr SHT_STRTAB SHF_ALLOC

.dynsym SHT_DYNSYM SHF_ALLOC

.fini SHT_PROGBITSSHF_ALLOC+SHF_EXECINSTR

.fini_array SHT_FINI_ARRAYSHF_ALLOC+SHF_WRITE

.got SHT_PROGBITSsee below

.hash SHT_HASH SHF_ALLOC

.init SHT_PROGBITSSHF_ALLOC+SHF_EXECINSTR

.init_array SHT_INIT_ARRAYSHF_ALLOC+SHF_WRITE

.interp SHT_PROGBITSsee below

.line SHT_PROGBITSnone

.note SHT_NOTE none

.plt SHT_PROGBITSsee below

.preinit_array SHT_PREINIT_ARRAYSHF_ALLOC+SHF_WRITE

.relname SHT_REL see below

.relaname SHT_RELA see below

.rodata SHT_PROGBITSSHF_ALLOC

.rodata1 SHT_PROGBITSSHF_ALLOC

.shstrtab SHT_STRTAB none

.strtab SHT_STRTAB see below

.symtab SHT_SYMTAB see below

.symtab_shndxSHT_SYMTAB_SHNDX see below

.tbss SHT_NOBITSSHF_ALLOC+SHF_WRITE+SHF_TLS

.tdata SHT_PROGBITSSHF_ALLOC+SHF_WRITE+SHF_TLS

.tdata1 SHT_PROGBITSSHF_ALLOC+SHF_WRITE+SHF_TLS

.text SHT_PROGBITSSHF_ALLOC+SHF_EXECINSTR

.bss

This section holds uninitialized data that contributeto the program's memory image.By definition, the system initializes the data with zeroswhen the program begins to run.The section occupies no file space, as indicated by the section type,SHT_NOBITS.

.comment

This section holds version control information.

.data and .data1

These sections hold initialized data that contributeto the program's memory image.

.debug

This section holds information for symbolic debugging.The contents are unspecified. All section names with theprefix .debug are reserved for future use in theABI.

.dynamic

This section holds dynamic linking information.The section's attributes will include the SHF_ALLOC bit.Whether the SHF_WRITE bit is set is processor specific.See Chapter 5 for more information.

.dynstr

This section holds strings needed for dynamic linking,most commonly the stringsthat represent the names associated with symbol table entries.See Chapter 5 for more information.

.dynsym

This section holds the dynamic linking symbol table,as described in``Symbol Table''.See Chapter 5 for more information.

.fini

This section holds executable instructions that contributeto the process termination code.That is, when a program exits normally, the system arrangesto execute the code in this section.

.fini_array

This section holds an array of function pointers that contributesto a single termination array for the executable or sharedobject containing the section.

.got

This section holds the global offset table.See ``Coding Examples'' in Chapter 3, ``Special Sections'' inChapter 4, and ``Global Offset Table'' in Chapter 5 of the processor supplement for more information.

.hash

This section holds a symbol hash table.See``Hash Table''in Chapter 5 for more information.

.init

This section holds executable instructions that contributeto the process initialization code.When a program starts to run, the system arrangesto execute the code in this section before calling themain program entry point (called main for C programs).

.init_array

This section holds an array of function pointers that contributesto a single initialization array for the executable or sharedobject containing the section.

.interp

This section holds the path name of a program interpreter.If the file has a loadable segment that includesrelocation, the sections' attributes will include theSHF_ALLOC bit; otherwise, that bit will be off.See Chapter 5 for more information.

.line

This section holds line number information for symbolicdebugging, which describesthe correspondence between the source program and themachine code.The contents are unspecified.

.note

This section holds information in the format that``Note Section''.in Chapter 5 describes.

.plt

This section holds the procedure linkage table.See ``Special Sections'' in Chapter 4 and ``Procedure LinkageTable'' in Chapter 5 of the processor supplement for moreinformation.

.preinit_array

This section holds an array of function pointers that contributesto a single pre-initialization array for the executable or sharedobject containing the section.

.relname and .relaname

These sections hold relocation information, as described in``Relocation''.If the file has a loadable segment that includesrelocation, the sections' attributes will include theSHF_ALLOC bit; otherwise, that bit will be off.Conventionally, nameis supplied by the section to which the relocations apply.Thus a relocation section for .textnormally would have the name .rel.text or .rela.text.

.rodata and .rodata1

These sections hold read-only data thattypically contribute to a non-writable segmentin the process image.See``Program Header''in Chapter 5 for more information.

.shstrtab

This section holds section names.

.strtab

This section holds strings, most commonly the stringsthat represent the names associated with symbol table entries.If the file has a loadable segment that includes thesymbol string table, the section's attributes will include theSHF_ALLOCbit; otherwise, that bit will be off.

.symtab

This section holds a symbol table, as``Symbol Table''.in this chapter describes.If the file has a loadable segment that includes thesymbol table, the section's attributes will include theSHF_ALLOC bit; otherwise, that bit will be off.

.symtab_shndx

This section holds the special symbol table section indexarray, as described above. The section's attributes will includethe SHF_ALLOC bit if the associated symbol tablesection does; otherwise that bit will be off.

.tbss

This section holds uninitialized thread-local data that contributeto the program's memory image.By definition,the system initializes the data with zeroswhen the data is instantiated for each new execution flow.The section occupies no file space, as indicated by the section type,SHT_NOBITS.Implementations need not support thread-local storage.

.tdata

This section holds initialized thread-local data that contributesto the program's memory image.A copy of its contents is instantiated by the systemfor each new execution flow.Implementations need not support thread-local storage.

.text

This section holds the ``text,'' or executableinstructions, of a program.

Section names with a dot (.) prefixare reserved for the system,although applications may use these sectionsif their existing meanings are satisfactory.Applications may use names without the prefix toavoid conflicts with system sections.The object file format lets one define sections notshown in the previous list.An object file may have more than one sectionwith the same name.

Section names reserved for a processor architectureare formed by placing an abbreviation of the architecturename ahead of the section name.The name should be taken from thearchitecture names used for e_machine.For instance .FOO.psect is the psectsection defined by the FOO architecture.Existing extensions are called by their historical names.

Pre-existing Extensions.sdata.tdesc

.sbss.lit4

.lit8.reginfo

.gptab.liblist

.conflict

For information on processor-specific sections,see the ABI supplement for the desired processor.