Adding upstream version 6.05.01.upstream/6.05.01

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 2196 insertions, 0 deletions

diff --git a/man5/elf.5 b/man5/elf.5
new file mode 100644
index 0000000..6fa4ddf
--- /dev/null
+++ b/man5/elf.5
@@ -0,0 +1,2196 @@
+.\"	$OpenBSD: elf.5,v 1.12 2003/10/27 20:23:58 jmc Exp $
+.\"Copyright (c) 1999 Jeroen Ruigrok van der Werven
+.\"All rights reserved.
+.\"
+.\" %%%LICENSE_START(PERMISSIVE_MISC)
+.\"Redistribution and use in source and binary forms, with or without
+.\"modification, are permitted provided that the following conditions
+.\"are met:
+.\"1. Redistributions of source code must retain the above copyright
+.\"   notice, this list of conditions and the following disclaimer.
+.\"2. Redistributions in binary form must reproduce the above copyright
+.\"   notice, this list of conditions and the following disclaimer in the
+.\"   documentation and/or other materials provided with the distribution.
+.\"
+.\"THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+.\"ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\"IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\"ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+.\"FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\"DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\"OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\"HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\"LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\"OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\"SUCH DAMAGE.
+.\" %%%LICENSE_END
+.\"
+.\"	$FreeBSD: src/share/man/man5/elf.5,v 1.21 2001/10/01 16:09:23 ru Exp $
+.\"
+.\" Slightly adapted - aeb, 2004-01-01
+.\" 2005-07-15, Mike Frysinger <vapier@gentoo.org>, various fixes
+.\" 2007-10-11, Mike Frysinger <vapier@gentoo.org>, various fixes
+.\" 2007-12-08, mtk, Converted from mdoc to man macros
+.\"
+.TH ELF 5 2023-05-03 "Linux man-pages 6.05.01"
+.SH NAME
+elf \- format of Executable and Linking Format (ELF) files
+.SH SYNOPSIS
+.nf
+.\" .B #include <elf_abi.h>
+.B #include <elf.h>
+.fi
+.SH DESCRIPTION
+The header file
+.I <elf.h>
+defines the format of ELF executable binary files.
+Amongst these files are
+normal executable files, relocatable object files, core files, and shared
+objects.
+.PP
+An executable file using the ELF file format consists of an ELF header,
+followed by a program header table or a section header table, or both.
+The ELF header is always at offset zero of the file.
+The program header
+table and the section header table's offset in the file are defined in the
+ELF header.
+The two tables describe the rest of the particularities of
+the file.
+.PP
+.\" Applications which wish to process ELF binary files for their native
+.\" architecture only should include
+.\" .I <elf_abi.h>
+.\" in their source code.
+.\" These applications should need to refer to
+.\" all the types and structures by their generic names
+.\" "Elf_xxx"
+.\" and to the macros by
+.\" ELF_xxx".
+.\" Applications written this way can be compiled on any architecture,
+.\" regardless of whether the host is 32-bit or 64-bit.
+.\" .PP
+.\" Should an application need to process ELF files of an unknown
+.\" architecture, then the application needs to explicitly use either
+.\" "Elf32_xxx"
+.\" or
+.\" "Elf64_xxx"
+.\" type and structure names.
+.\" Likewise, the macros need to be identified by
+.\" "ELF32_xxx"
+.\" or
+.\" "ELF64_xxx".
+.\" .PP
+This header file describes the above mentioned headers as C structures
+and also includes structures for dynamic sections, relocation sections and
+symbol tables.
+.\"
+.SS Basic types
+The following types are used for N-bit architectures (N=32,64,
+.I ElfN
+stands for
+.I Elf32
+or
+.IR Elf64 ,
+.I uintN_t
+stands for
+.I uint32_t
+or
+.IR uint64_t ):
+.PP
+.in +4n
+.EX
+ElfN_Addr       Unsigned program address, uintN_t
+ElfN_Off        Unsigned file offset, uintN_t
+ElfN_Section    Unsigned section index, uint16_t
+ElfN_Versym     Unsigned version symbol information, uint16_t
+Elf_Byte        unsigned char
+ElfN_Half       uint16_t
+ElfN_Sword      int32_t
+ElfN_Word       uint32_t
+ElfN_Sxword     int64_t
+ElfN_Xword      uint64_t
+.\" Elf32_Size  Unsigned object size
+.EE
+.in
+.PP
+(Note: the *BSD terminology is a bit different.
+There,
+.I Elf64_Half
+is
+twice as large as
+.IR Elf32_Half ,
+and
+.I Elf64Quarter
+is used for
+.IR uint16_t .
+In order to avoid confusion these types are replaced by explicit ones
+in the below.)
+.PP
+All data structures that the file format defines follow the
+"natural"
+size and alignment guidelines for the relevant class.
+If necessary,
+data structures contain explicit padding to ensure 4-byte alignment
+for 4-byte objects, to force structure sizes to a multiple of 4, and so on.
+.\"
+.SS ELF header (Ehdr)
+The ELF header is described by the type
+.I Elf32_Ehdr
+or
+.IR Elf64_Ehdr :
+.PP
+.in +4n
+.EX
+#define EI_NIDENT 16
+\&
+typedef struct {
+    unsigned char e_ident[EI_NIDENT];
+    uint16_t      e_type;
+    uint16_t      e_machine;
+    uint32_t      e_version;
+    ElfN_Addr     e_entry;
+    ElfN_Off      e_phoff;
+    ElfN_Off      e_shoff;
+    uint32_t      e_flags;
+    uint16_t      e_ehsize;
+    uint16_t      e_phentsize;
+    uint16_t      e_phnum;
+    uint16_t      e_shentsize;
+    uint16_t      e_shnum;
+    uint16_t      e_shstrndx;
+} ElfN_Ehdr;
+.EE
+.in
+.PP
+The fields have the following meanings:
+.\"
+.\"
+.TP
+.I e_ident
+This array of bytes specifies how to interpret the file,
+independent of the processor or the file's remaining contents.
+Within this array everything is named by macros, which start with
+the prefix
+.B EI_
+and may contain values which start with the prefix
+.BR ELF .
+The following macros are defined:
+.RS
+.TP
+.B EI_MAG0
+The first byte of the magic number.
+It must be filled with
+.BR ELFMAG0 .
+(0: 0x7f)
+.TP
+.B EI_MAG1
+The second byte of the magic number.
+It must be filled with
+.BR ELFMAG1 .
+(1: \[aq]E\[aq])
+.TP
+.B EI_MAG2
+The third byte of the magic number.
+It must be filled with
+.BR ELFMAG2 .
+(2: \[aq]L\[aq])
+.TP
+.B EI_MAG3
+The fourth byte of the magic number.
+It must be filled with
+.BR ELFMAG3 .
+(3: \[aq]F\[aq])
+.TP
+.B EI_CLASS
+The fifth byte identifies the architecture for this binary:
+.RS
+.TP 14
+.PD 0
+.B ELFCLASSNONE
+This class is invalid.
+.TP
+.B ELFCLASS32
+This defines the 32-bit architecture.
+It supports machines with files
+and virtual address spaces up to 4 Gigabytes.
+.TP
+.B ELFCLASS64
+This defines the 64-bit architecture.
+.PD
+.RE
+.TP
+.B EI_DATA
+The sixth byte specifies the data encoding of the processor-specific
+data in the file.
+Currently, these encodings are supported:
+.RS 9
+.TP 14
+.PD 0
+.B ELFDATANONE
+Unknown data format.
+.TP
+.B ELFDATA2LSB
+Two's complement, little-endian.
+.TP
+.B ELFDATA2MSB
+Two's complement, big-endian.
+.PD
+.RE
+.TP
+.B EI_VERSION
+The seventh byte is the version number of the ELF specification:
+.IP
+.PD 0
+.RS
+.TP 14
+.B EV_NONE
+Invalid version.
+.TP
+.B EV_CURRENT
+Current version.
+.PD
+.RE
+.\".El
+.TP
+.B EI_OSABI
+The eighth byte identifies the operating system
+and ABI to which the object is targeted.
+Some fields in other ELF structures have flags
+and values that have platform-specific meanings;
+the interpretation of those fields is determined by the value of this byte.
+For example:
+.RS
+.TP 21
+.PD 0
+.B ELFOSABI_NONE
+Same as ELFOSABI_SYSV
+.\" 0
+.TP
+.B ELFOSABI_SYSV
+UNIX System V ABI
+.\" 0
+.\" synonym: ELFOSABI_NONE
+.TP
+.B ELFOSABI_HPUX
+HP-UX ABI
+.\" 1
+.TP
+.B ELFOSABI_NETBSD
+NetBSD ABI
+.\" 2
+.TP
+.B ELFOSABI_LINUX
+Linux ABI
+.\" 3
+.\" .TP
+.\" .BR ELFOSABI_HURD
+.\" Hurd ABI
+.\" 4
+.\" .TP
+.\" .BR ELFOSABI_86OPEN
+.\" 86Open Common IA32 ABI
+.\" 5
+.TP
+.B ELFOSABI_SOLARIS
+Solaris ABI
+.\" 6
+.\" .TP
+.\" .BR ELFOSABI_MONTEREY
+.\" Monterey project ABI
+.\" Now replaced by
+.\" ELFOSABI_AIX
+.\" 7
+.TP
+.B ELFOSABI_IRIX
+IRIX ABI
+.\" 8
+.TP
+.B ELFOSABI_FREEBSD
+FreeBSD ABI
+.\" 9
+.TP
+.B ELFOSABI_TRU64
+TRU64 UNIX ABI
+.\" 10
+.\" ELFOSABI_MODESTO
+.\" 11
+.\" ELFOSABI_OPENBSD
+.\" 12
+.TP
+.B ELFOSABI_ARM
+ARM architecture ABI
+.\" 97
+.TP
+.B ELFOSABI_STANDALONE
+Stand-alone (embedded) ABI
+.\" 255
+.PD
+.RE
+.TP
+.B EI_ABIVERSION
+The ninth byte identifies the version of the ABI
+to which the object is targeted.
+This field is used to distinguish among incompatible versions of an ABI.
+The interpretation of this version number
+is dependent on the ABI identified by the
+.B EI_OSABI
+field.
+Applications conforming to this specification use the value 0.
+.TP
+.B EI_PAD
+Start of padding.
+These bytes are reserved and set to zero.
+Programs
+which read them should ignore them.
+The value for
+.B EI_PAD
+will change in
+the future if currently unused bytes are given meanings.
+.\" As reported by Yuri Kozlov and confirmed by Mike Frysinger, EI_BRAND is
+.\" not in GABI (http://www.sco.com/developers/gabi/latest/ch4.eheader.html)
+.\" It looks to be a BSDism
+.\" .TP
+.\" .BR EI_BRAND
+.\" Start of architecture identification.
+.TP
+.B EI_NIDENT
+The size of the
+.I e_ident
+array.
+.RE
+.TP
+.I e_type
+This member of the structure identifies the object file type:
+.RS
+.TP 16
+.PD 0
+.B ET_NONE
+An unknown type.
+.TP
+.B ET_REL
+A relocatable file.
+.TP
+.B ET_EXEC
+An executable file.
+.TP
+.B ET_DYN
+A shared object.
+.TP
+.B ET_CORE
+A core file.
+.PD
+.RE
+.TP
+.I e_machine
+This member specifies the required architecture for an individual file.
+For example:
+.RS
+.TP 16
+.PD 0
+.B EM_NONE
+An unknown machine
+.\" 0
+.TP
+.B EM_M32
+AT&T WE 32100
+.\" 1
+.TP
+.B EM_SPARC
+Sun Microsystems SPARC
+.\" 2
+.TP
+.B EM_386
+Intel 80386
+.\" 3
+.TP
+.B EM_68K
+Motorola 68000
+.\" 4
+.TP
+.B EM_88K
+Motorola 88000
+.\" 5
+.\" .TP
+.\" .BR EM_486
+.\" Intel 80486
+.\" 6
+.TP
+.B EM_860
+Intel 80860
+.\" 7
+.TP
+.B EM_MIPS
+MIPS RS3000 (big-endian only)
+.\" 8
+.\" EM_S370
+.\" 9
+.\" .TP
+.\" .BR EM_MIPS_RS4_BE
+.\" MIPS RS4000 (big-endian only). Deprecated
+.\" 10
+.\" EM_MIPS_RS3_LE (MIPS R3000 little-endian)
+.\" 10
+.TP
+.B EM_PARISC
+HP/PA
+.\" 15
+.TP
+.B EM_SPARC32PLUS
+SPARC with enhanced instruction set
+.\" 18
+.TP
+.B EM_PPC
+PowerPC
+.\" 20
+.TP
+.B EM_PPC64
+PowerPC 64-bit
+.\" 21
+.TP
+.B EM_S390
+IBM S/390
+.\" 22
+.TP
+.B EM_ARM
+Advanced RISC Machines
+.\" 40
+.TP
+.B EM_SH
+Renesas SuperH
+.\" 42
+.TP
+.B EM_SPARCV9
+SPARC v9 64-bit
+.\" 43
+.TP
+.B EM_IA_64
+Intel Itanium
+.\" 50
+.TP
+.B EM_X86_64
+AMD x86-64
+.\" 62
+.TP
+.B EM_VAX
+DEC Vax
+.\" 75
+.\" EM_CRIS
+.\" 76
+.\" .TP
+.\" .BR EM_ALPHA
+.\" Compaq [DEC] Alpha
+.\" .TP
+.\" .BR EM_ALPHA_EXP
+.\" Compaq [DEC] Alpha with enhanced instruction set
+.PD
+.RE
+.TP
+.I e_version
+This member identifies the file version:
+.RS
+.TP 16
+.PD 0
+.B EV_NONE
+Invalid version
+.TP
+.B EV_CURRENT
+Current version
+.PD
+.RE
+.TP
+.I e_entry
+This member gives the virtual address to which the system first transfers
+control, thus starting the process.
+If the file has no associated entry
+point, this member holds zero.
+.TP
+.I e_phoff
+This member holds the program header table's file offset in bytes.
+If
+the file has no program header table, this member holds zero.
+.TP
+.I e_shoff
+This member holds the section header table's file offset in bytes.
+If the
+file has no section header table, this member holds zero.
+.TP
+.I e_flags
+This member holds processor-specific flags associated with the file.
+Flag names take the form EF_`machine_flag'.
+Currently, no flags have been defined.
+.TP
+.I e_ehsize
+This member holds the ELF header's size in bytes.
+.TP
+.I e_phentsize
+This member holds the size in bytes of one entry in the file's
+program header table; all entries are the same size.
+.TP
+.I e_phnum
+This member holds the number of entries in the program header
+table.
+Thus the product of
+.I e_phentsize
+and
+.I e_phnum
+gives the table's size
+in bytes.
+If a file has no program header,
+.I e_phnum
+holds the value zero.
+.IP
+If the number of entries in the program header table is
+larger than or equal to
+.\" This is a Linux extension, added in Linux 2.6.34.
+.B PN_XNUM
+(0xffff), this member holds
+.B PN_XNUM
+(0xffff) and the real number of entries in the program header table is held
+in the
+.I sh_info
+member of the initial entry in section header table.
+Otherwise, the
+.I sh_info
+member of the initial entry contains the value zero.
+.RS
+.TP
+.B PN_XNUM
+This is defined as 0xffff, the largest number
+.I e_phnum
+can have, specifying where the actual number of program headers is assigned.
+.PD
+.RE
+.TP
+.I e_shentsize
+This member holds a sections header's size in bytes.
+A section header is one
+entry in the section header table; all entries are the same size.
+.TP
+.I e_shnum
+This member holds the number of entries in the section header table.
+Thus
+the product of
+.I e_shentsize
+and
+.I e_shnum
+gives the section header table's size in bytes.
+If a file has no section
+header table,
+.I e_shnum
+holds the value of zero.
+.IP
+If the number of entries in the section header table is
+larger than or equal to
+.B SHN_LORESERVE
+(0xff00),
+.I e_shnum
+holds the value zero and the real number of entries in the section header
+table is held in the
+.I sh_size
+member of the initial entry in section header table.
+Otherwise, the
+.I sh_size
+member of the initial entry in the section header table holds
+the value zero.
+.TP
+.I e_shstrndx
+This member holds the section header table index of the entry associated
+with the section name string table.
+If the file has no section name string
+table, this member holds the value
+.BR SHN_UNDEF .
+.IP
+If the index of section name string table section is
+larger than or equal to
+.B SHN_LORESERVE
+(0xff00), this member holds
+.B SHN_XINDEX
+(0xffff) and the real index of the section name string table section
+is held in the
+.I sh_link
+member of the initial entry in section header table.
+Otherwise, the
+.I sh_link
+member of the initial entry in section header table contains the value zero.
+.\"
+.SS Program header (Phdr)
+An executable or shared object file's program header table is an array of
+structures, each describing a segment or other information the system needs
+to prepare the program for execution.
+An object file
+.I segment
+contains one or more
+.IR sections .
+Program headers are meaningful only for executable and shared object files.
+A file specifies its own program header size with the ELF header's
+.I e_phentsize
+and
+.I e_phnum
+members.
+The ELF program header is described by the type
+.I Elf32_Phdr
+or
+.I Elf64_Phdr
+depending on the architecture:
+.PP
+.in +4n
+.EX
+typedef struct {
+    uint32_t   p_type;
+    Elf32_Off  p_offset;
+    Elf32_Addr p_vaddr;
+    Elf32_Addr p_paddr;
+    uint32_t   p_filesz;
+    uint32_t   p_memsz;
+    uint32_t   p_flags;
+    uint32_t   p_align;
+} Elf32_Phdr;
+.EE
+.in
+.PP
+.in +4n
+.EX
+typedef struct {
+    uint32_t   p_type;
+    uint32_t   p_flags;
+    Elf64_Off  p_offset;
+    Elf64_Addr p_vaddr;
+    Elf64_Addr p_paddr;
+    uint64_t   p_filesz;
+    uint64_t   p_memsz;
+    uint64_t   p_align;
+} Elf64_Phdr;
+.EE
+.in
+.PP
+The main difference between the 32-bit and the 64-bit program header lies
+in the location of the
+.I p_flags
+member in the total struct.
+.TP
+.I p_type
+This member of the structure indicates what kind of segment this array
+element describes or how to interpret the array element's information.
+.RS 10
+.TP
+.B PT_NULL
+The array element is unused and the other members' values are undefined.
+This lets the program header have ignored entries.
+.TP
+.B PT_LOAD
+The array element specifies a loadable segment, described by
+.I p_filesz
+and
+.IR p_memsz .
+The bytes from the file are mapped to the beginning of the memory
+segment.
+If the segment's memory size
+.I p_memsz
+is larger than the file size
+.IR p_filesz ,
+the
+"extra"
+bytes are defined to hold the value 0 and to follow the segment's
+initialized area.
+The file size may not be larger than the memory size.
+Loadable segment entries in the program header table appear in ascending
+order, sorted on the
+.I p_vaddr
+member.
+.TP
+.B PT_DYNAMIC
+The array element specifies dynamic linking information.
+.TP
+.B PT_INTERP
+The array element specifies the location and size of a null-terminated
+pathname to invoke as an interpreter.
+This segment type is meaningful
+only for executable files (though it may occur for shared objects).
+However it may not occur more than once in a file.
+If it is present, it must precede any loadable segment entry.
+.TP
+.B PT_NOTE
+The array element specifies the location of notes (ElfN_Nhdr).
+.TP
+.B PT_SHLIB
+This segment type is reserved but has unspecified semantics.
+Programs that
+contain an array element of this type do not conform to the ABI.
+.TP
+.B PT_PHDR
+The array element, if present,
+specifies the location and size of the program header table itself,
+both in the file and in the memory image of the program.
+This segment type may not occur more than once in a file.
+Moreover, it may
+occur only if the program header table is part of the memory image of the
+program.
+If it is present, it must precede any loadable segment entry.
+.TP
+.BR PT_LOPROC ", " PT_HIPROC
+Values in the inclusive range
+.RB [ PT_LOPROC ,
+.BR PT_HIPROC ]
+are reserved for processor-specific semantics.
+.TP
+.B PT_GNU_STACK
+GNU extension which is used by the Linux kernel to control the state of the
+stack via the flags set in the
+.I p_flags
+member.
+.RE
+.TP
+.I p_offset
+This member holds the offset from the beginning of the file at which
+the first byte of the segment resides.
+.TP
+.I p_vaddr
+This member holds the virtual address at which the first byte of the
+segment resides in memory.
+.TP
+.I p_paddr
+On systems for which physical addressing is relevant, this member is
+reserved for the segment's physical address.
+Under
+BSD
+this member is
+not used and must be zero.
+.TP
+.I p_filesz
+This member holds the number of bytes in the file image of the segment.
+It may be zero.
+.TP
+.I p_memsz
+This member holds the number of bytes in the memory image of the segment.
+It may be zero.
+.TP
+.I p_flags
+This member holds a bit mask of flags relevant to the segment:
+.RS
+.TP
+.PD 0
+.B PF_X
+An executable segment.
+.TP
+.B PF_W
+A writable segment.
+.TP
+.B PF_R
+A readable segment.
+.PD
+.RE
+.IP
+A text segment commonly has the flags
+.B PF_X
+and
+.B PF_R .
+A data segment commonly has
+.B PF_W
+and
+.BR PF_R .
+.TP
+.I p_align
+This member holds the value to which the segments are aligned in memory
+and in the file.
+Loadable process segments must have congruent values for
+.I p_vaddr
+and
+.IR p_offset ,
+modulo the page size.
+Values of zero and one mean no alignment is required.
+Otherwise,
+.I p_align
+should be a positive, integral power of two, and
+.I p_vaddr
+should equal
+.IR p_offset ,
+modulo
+.IR p_align .
+.\"
+.SS Section header (Shdr)
+A file's section header table lets one locate all the file's sections.
+The
+section header table is an array of
+.I Elf32_Shdr
+or
+.I Elf64_Shdr
+structures.
+The
+ELF header's
+.I e_shoff
+member gives the byte offset from the beginning of the file to the section
+header table.
+.I e_shnum
+holds the number of entries the section header table contains.
+.I e_shentsize
+holds the size in bytes of each entry.
+.PP
+A section header table index is a subscript into this array.
+Some section
+header table indices are reserved:
+the initial entry and the indices between
+.B SHN_LORESERVE
+and
+.BR SHN_HIRESERVE .
+The initial entry is used in ELF extensions for
+.IR e_phnum ,
+.IR e_shnum ,
+and
+.IR e_shstrndx ;
+in other cases, each field in the initial entry is set to zero.
+An object file does not have sections for
+these special indices:
+.TP
+.B SHN_UNDEF
+This value marks an undefined, missing, irrelevant,
+or otherwise meaningless section reference.
+.TP
+.B SHN_LORESERVE
+This value specifies the lower bound of the range of reserved indices.
+.TP
+.BR SHN_LOPROC ", " SHN_HIPROC
+Values greater in the inclusive range
+.RB [ SHN_LOPROC ,
+.BR SHN_HIPROC ]
+are reserved for processor-specific semantics.
+.TP
+.B SHN_ABS
+This value specifies the absolute value for the corresponding reference.
+For
+example, a symbol defined relative to section number
+.B SHN_ABS
+has an absolute value and is not affected by relocation.
+.TP
+.B SHN_COMMON
+Symbols defined relative to this section are common symbols,
+such as FORTRAN COMMON or unallocated C external variables.
+.TP
+.B SHN_HIRESERVE
+This value specifies the upper bound of the range of reserved indices.
+The
+system reserves indices between
+.B SHN_LORESERVE
+and
+.BR SHN_HIRESERVE ,
+inclusive.
+The section header table does not contain entries for the
+reserved indices.
+.PP
+The section header has the following structure:
+.PP
+.in +4n
+.EX
+typedef struct {
+    uint32_t   sh_name;
+    uint32_t   sh_type;
+    uint32_t   sh_flags;
+    Elf32_Addr sh_addr;
+    Elf32_Off  sh_offset;
+    uint32_t   sh_size;
+    uint32_t   sh_link;
+    uint32_t   sh_info;
+    uint32_t   sh_addralign;
+    uint32_t   sh_entsize;
+} Elf32_Shdr;
+.EE
+.in
+.PP
+.in +4n
+.EX
+typedef struct {
+    uint32_t   sh_name;
+    uint32_t   sh_type;
+    uint64_t   sh_flags;
+    Elf64_Addr sh_addr;
+    Elf64_Off  sh_offset;
+    uint64_t   sh_size;
+    uint32_t   sh_link;
+    uint32_t   sh_info;
+    uint64_t   sh_addralign;
+    uint64_t   sh_entsize;
+} Elf64_Shdr;
+.EE
+.in
+.PP
+No real differences exist between the 32-bit and 64-bit section headers.
+.TP
+.I sh_name
+This member specifies the name of the section.
+Its value is an index
+into the section header string table section, giving the location of
+a null-terminated string.
+.TP
+.I sh_type
+This member categorizes the section's contents and semantics.
+.RS
+.TP
+.B 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.
+.TP
+.B SHT_PROGBITS
+This section holds information defined by the program, whose
+format and meaning are determined solely by the program.
+.TP
+.B SHT_SYMTAB
+This section holds a symbol table.
+Typically,
+.B SHT_SYMTAB
+provides symbols for link editing, though it may also be used
+for dynamic linking.
+As a complete symbol table, it may contain
+many symbols unnecessary for dynamic linking.
+An object file can
+also contain a
+.B SHT_DYNSYM
+section.
+.TP
+.B SHT_STRTAB
+This section holds a string table.
+An object file may have multiple
+string table sections.
+.TP
+.B SHT_RELA
+This section holds relocation entries with explicit addends, such
+as type
+.I Elf32_Rela
+for the 32-bit class of object files.
+An object may have multiple
+relocation sections.
+.TP
+.B SHT_HASH
+This section holds a symbol hash table.
+An object participating in
+dynamic linking must contain a symbol hash table.
+An object file may
+have only one hash table.
+.TP
+.B SHT_DYNAMIC
+This section holds information for dynamic linking.
+An object file may
+have only one dynamic section.
+.TP
+.B SHT_NOTE
+This section holds notes (ElfN_Nhdr).
+.TP
+.B SHT_NOBITS
+A section of this type occupies no space in the file but otherwise
+resembles
+.BR SHT_PROGBITS .
+Although this section contains no bytes, the
+.I sh_offset
+member contains the conceptual file offset.
+.TP
+.B SHT_REL
+This section holds relocation offsets without explicit addends, such
+as type
+.I Elf32_Rel
+for the 32-bit class of object files.
+An object file may have multiple
+relocation sections.
+.TP
+.B SHT_SHLIB
+This section is reserved but has unspecified semantics.
+.TP
+.B SHT_DYNSYM
+This section holds a minimal set of dynamic linking symbols.
+An
+object file can also contain a
+.B SHT_SYMTAB
+section.
+.TP
+.BR SHT_LOPROC ", " SHT_HIPROC
+Values in the inclusive range
+.RB [ SHT_LOPROC ,
+.BR SHT_HIPROC ]
+are reserved for processor-specific semantics.
+.TP
+.B SHT_LOUSER
+This value specifies the lower bound of the range of indices reserved for
+application programs.
+.TP
+.B SHT_HIUSER
+This value specifies the upper bound of the range of indices reserved for
+application programs.
+Section types between
+.B SHT_LOUSER
+and
+.B SHT_HIUSER
+may be used by the application, without conflicting with current or future
+system-defined section types.
+.RE
+.TP
+.I sh_flags
+Sections support one-bit flags that describe miscellaneous attributes.
+If a flag bit is set in
+.IR sh_flags ,
+the attribute is
+"on"
+for the section.
+Otherwise, the attribute is
+"off"
+or does not apply.
+Undefined attributes are set to zero.
+.RS
+.TP
+.B SHF_WRITE
+This section contains data that should be writable during process
+execution.
+.TP
+.B SHF_ALLOC
+This section occupies memory during process execution.
+Some control
+sections do not reside in the memory image of an object file.
+This
+attribute is off for those sections.
+.TP
+.B SHF_EXECINSTR
+This section contains executable machine instructions.
+.TP
+.B SHF_MASKPROC
+All bits included in this mask are reserved for processor-specific
+semantics.
+.RE
+.TP
+.I sh_addr
+If this section appears in the memory image of a process, this member
+holds the address at which the section's first byte should reside.
+Otherwise, the member contains zero.
+.TP
+.I sh_offset
+This member's value holds the byte offset from the beginning of the file
+to the first byte in the section.
+One section type,
+.BR SHT_NOBITS ,
+occupies no space in the file, and its
+.I sh_offset
+member locates the conceptual placement in the file.
+.TP
+.I sh_size
+This member holds the section's size in bytes.
+Unless the section type
+is
+.BR SHT_NOBITS ,
+the section occupies
+.I sh_size
+bytes in the file.
+A section of type
+.B SHT_NOBITS
+may have a nonzero size, but it occupies no space in the file.
+.TP
+.I sh_link
+This member holds a section header table index link, whose interpretation
+depends on the section type.
+.TP
+.I sh_info
+This member holds extra information, whose interpretation depends on the
+section type.
+.TP
+.I sh_addralign
+Some sections have address alignment constraints.
+If a section holds a
+doubleword, the system must ensure doubleword alignment for the entire
+section.
+That is, the value of
+.I sh_addr
+must be congruent to zero, modulo the value of
+.IR sh_addralign .
+Only zero and positive integral powers of two are allowed.
+The value 0 or 1 means that the section has no alignment constraints.
+.TP
+.I sh_entsize
+Some sections hold a table of fixed-sized entries, such as a symbol table.
+For such a section, this member gives the size in bytes for each entry.
+This member contains zero if the section does not hold a table of
+fixed-size entries.
+.PP
+Various sections hold program and control information:
+.TP
+.I .bss
+This section holds uninitialized data that contributes to the program's
+memory image.
+By definition, the system initializes the data with zeros
+when the program begins to run.
+This section is of type
+.BR SHT_NOBITS .
+The attribute types are
+.B SHF_ALLOC
+and
+.BR SHF_WRITE .
+.TP
+.I .comment
+This section holds version control information.
+This section is of type
+.BR SHT_PROGBITS .
+No attribute types are used.
+.TP
+.I .ctors
+This section holds initialized pointers to the C++ constructor functions.
+This section is of type
+.BR SHT_PROGBITS .
+The attribute types are
+.B SHF_ALLOC
+and
+.BR SHF_WRITE .
+.TP
+.I .data
+This section holds initialized data that contribute to the program's
+memory image.
+This section is of type
+.BR SHT_PROGBITS .
+The attribute types are
+.B SHF_ALLOC
+and
+.BR SHF_WRITE .
+.TP
+.I .data1
+This section holds initialized data that contribute to the program's
+memory image.
+This section is of type
+.BR SHT_PROGBITS .
+The attribute types are
+.B SHF_ALLOC
+and
+.BR SHF_WRITE .
+.TP
+.I .debug
+This section holds information for symbolic debugging.
+The contents
+are unspecified.
+This section is of type
+.BR SHT_PROGBITS .
+No attribute types are used.
+.TP
+.I .dtors
+This section holds initialized pointers to the C++ destructor functions.
+This section is of type
+.BR SHT_PROGBITS .
+The attribute types are
+.B SHF_ALLOC
+and
+.BR SHF_WRITE .
+.TP
+.I .dynamic
+This section holds dynamic linking information.
+The section's attributes
+will include the
+.B SHF_ALLOC
+bit.
+Whether the
+.B SHF_WRITE
+bit is set is processor-specific.
+This section is of type
+.BR SHT_DYNAMIC .
+See the attributes above.
+.TP
+.I .dynstr
+This section holds strings needed for dynamic linking, most commonly
+the strings that represent the names associated with symbol table entries.
+This section is of type
+.BR SHT_STRTAB .
+The attribute type used is
+.BR SHF_ALLOC .
+.TP
+.I .dynsym
+This section holds the dynamic linking symbol table.
+This section is of type
+.BR SHT_DYNSYM .
+The attribute used is
+.BR SHF_ALLOC .
+.TP
+.I .fini
+This section holds executable instructions that contribute to the process
+termination code.
+When a program exits normally the system arranges to
+execute the code in this section.
+This section is of type
+.BR SHT_PROGBITS .
+The attributes used are
+.B SHF_ALLOC
+and
+.BR SHF_EXECINSTR .
+.TP
+.I .gnu.version
+This section holds the version symbol table, an array of
+.I ElfN_Half
+elements.
+This section is of type
+.BR SHT_GNU_versym .
+The attribute type used is
+.BR SHF_ALLOC .
+.TP
+.I .gnu.version_d
+This section holds the version symbol definitions, a table of
+.I ElfN_Verdef
+structures.
+This section is of type
+.BR SHT_GNU_verdef .
+The attribute type used is
+.BR SHF_ALLOC .
+.TP
+.I .gnu.version_r
+This section holds the version symbol needed elements, a table of
+.I ElfN_Verneed
+structures.
+This section is of
+type
+.BR SHT_GNU_versym .
+The attribute type used is
+.BR SHF_ALLOC .
+.TP
+.I .got
+This section holds the global offset table.
+This section is of type
+.BR SHT_PROGBITS .
+The attributes are processor-specific.
+.TP
+.I .hash
+This section holds a symbol hash table.
+This section is of type
+.BR SHT_HASH .
+The attribute used is
+.BR SHF_ALLOC .
+.TP
+.I .init
+This section holds executable instructions that contribute to the process
+initialization code.
+When a program starts to run the system arranges to execute
+the code in this section before calling the main program entry point.
+This section is of type
+.BR SHT_PROGBITS .
+The attributes used are
+.B SHF_ALLOC
+and
+.BR SHF_EXECINSTR .
+.TP
+.I .interp
+This section holds the pathname of a program interpreter.
+If the file has
+a loadable segment that includes the section, the section's attributes will
+include the
+.B SHF_ALLOC
+bit.
+Otherwise, that bit will be off.
+This section is of type
+.BR SHT_PROGBITS .
+.TP
+.I .line
+This section holds line number information for symbolic debugging,
+which describes the correspondence between the program source and
+the machine code.
+The contents are unspecified.
+This section is of type
+.BR SHT_PROGBITS .
+No attribute types are used.
+.TP
+.I .note
+This section holds various notes.
+This section is of type
+.BR SHT_NOTE .
+No attribute types are used.
+.TP
+.I .note.ABI\-tag
+This section is used to declare the expected run-time ABI of the ELF image.
+It may include the operating system name and its run-time versions.
+This section is of type
+.BR SHT_NOTE .
+The only attribute used is
+.BR SHF_ALLOC .
+.TP
+.I .note.gnu.build\-id
+This section is used to hold an ID that uniquely identifies
+the contents of the ELF image.
+Different files with the same build ID should contain the same executable
+content.
+See the
+.B \-\-build\-id
+option to the GNU linker (\fBld\fR (1)) for more details.
+This section is of type
+.BR SHT_NOTE .
+The only attribute used is
+.BR SHF_ALLOC .
+.TP
+.I .note.GNU\-stack
+This section is used in Linux object files for declaring stack attributes.
+This section is of type
+.BR SHT_PROGBITS .
+The only attribute used is
+.BR SHF_EXECINSTR .
+This indicates to the GNU linker that the object file requires an
+executable stack.
+.TP
+.I .note.openbsd.ident
+OpenBSD native executables usually contain this section
+to identify themselves so the kernel can bypass any compatibility
+ELF binary emulation tests when loading the file.
+.TP
+.I .plt
+This section holds the procedure linkage table.
+This section is of type
+.BR SHT_PROGBITS .
+The attributes are processor-specific.
+.TP
+.I .relNAME
+This section holds relocation information as described below.
+If the file
+has a loadable segment that includes relocation, the section's attributes
+will include the
+.B SHF_ALLOC
+bit.
+Otherwise, the bit will be off.
+By convention,
+"NAME"
+is supplied by the section to which the relocations apply.
+Thus a relocation
+section for
+.B .text
+normally would have the name
+.BR .rel.text .
+This section is of type
+.BR SHT_REL .
+.TP
+.I .relaNAME
+This section holds relocation information as described below.
+If the file
+has a loadable segment that includes relocation, the section's attributes
+will include the
+.B SHF_ALLOC
+bit.
+Otherwise, the bit will be off.
+By convention,
+"NAME"
+is supplied by the section to which the relocations apply.
+Thus a relocation
+section for
+.B .text
+normally would have the name
+.BR .rela.text .
+This section is of type
+.BR SHT_RELA .
+.TP
+.I .rodata
+This section holds read-only data that typically contributes to a
+nonwritable segment in the process image.
+This section is of type
+.BR SHT_PROGBITS .
+The attribute used is
+.BR SHF_ALLOC .
+.TP
+.I .rodata1
+This section holds read-only data that typically contributes to a
+nonwritable segment in the process image.
+This section is of type
+.BR SHT_PROGBITS .
+The attribute used is
+.BR SHF_ALLOC .
+.TP
+.I .shstrtab
+This section holds section names.
+This section is of type
+.BR SHT_STRTAB .
+No attribute types are used.
+.TP
+.I .strtab
+This section holds strings, most commonly the strings that represent the
+names associated with symbol table entries.
+If the file has a loadable
+segment that includes the symbol string table, the section's attributes
+will include the
+.B SHF_ALLOC
+bit.
+Otherwise, the bit will be off.
+This section is of type
+.BR SHT_STRTAB .
+.TP
+.I .symtab
+This section holds a symbol table.
+If the file has a loadable segment
+that includes the symbol table, the section's attributes will include
+the
+.B SHF_ALLOC
+bit.
+Otherwise, the bit will be off.
+This section is of type
+.BR SHT_SYMTAB .
+.TP
+.I .text
+This section holds the
+"text",
+or executable instructions, of a program.
+This section is of type
+.BR SHT_PROGBITS .
+The attributes used are
+.B SHF_ALLOC
+and
+.BR SHF_EXECINSTR .
+.\"
+.SS String and symbol tables
+String table sections hold null-terminated character sequences, commonly
+called strings.
+The object file uses these strings to represent symbol
+and section names.
+One references a string as an index into the string
+table section.
+The first byte, which is index zero, is defined to hold
+a null byte (\[aq]\e0\[aq]).
+Similarly, a string table's last byte is defined to
+hold a null byte, ensuring null termination for all strings.
+.PP
+An object file's symbol table holds information needed to locate and
+relocate a program's symbolic definitions and references.
+A symbol table
+index is a subscript into this array.
+.PP
+.in +4n
+.EX
+typedef struct {
+    uint32_t      st_name;
+    Elf32_Addr    st_value;
+    uint32_t      st_size;
+    unsigned char st_info;
+    unsigned char st_other;
+    uint16_t      st_shndx;
+} Elf32_Sym;
+.EE
+.in
+.PP
+.in +4n
+.EX
+typedef struct {
+    uint32_t      st_name;
+    unsigned char st_info;
+    unsigned char st_other;
+    uint16_t      st_shndx;
+    Elf64_Addr    st_value;
+    uint64_t      st_size;
+} Elf64_Sym;
+.EE
+.in
+.PP
+The 32-bit and 64-bit versions have the same members, just in a different
+order.
+.TP
+.I st_name
+This member holds an index into the object file's symbol string table,
+which holds character representations of the symbol names.
+If the value
+is nonzero, it represents a string table index that gives the symbol
+name.
+Otherwise, the symbol has no name.
+.TP
+.I st_value
+This member gives the value of the associated symbol.
+.TP
+.I st_size
+Many symbols have associated sizes.
+This member holds zero if the symbol
+has no size or an unknown size.
+.TP
+.I st_info
+This member specifies the symbol's type and binding attributes:
+.RS
+.TP
+.B STT_NOTYPE
+The symbol's type is not defined.
+.TP
+.B STT_OBJECT
+The symbol is associated with a data object.
+.TP
+.B STT_FUNC
+The symbol is associated with a function or other executable code.
+.TP
+.B STT_SECTION
+The symbol is associated with a section.
+Symbol table entries of
+this type exist primarily for relocation and normally have
+.B STB_LOCAL
+bindings.
+.TP
+.B STT_FILE
+By convention, the symbol's name gives the name of the source file
+associated with the object file.
+A file symbol has
+.B STB_LOCAL
+bindings, its section index is
+.BR SHN_ABS ,
+and it precedes the other
+.B STB_LOCAL
+symbols of the file, if it is present.
+.TP
+.BR STT_LOPROC ", " STT_HIPROC
+Values in the inclusive range
+.RB [ STT_LOPROC ,
+.BR STT_HIPROC ]
+are reserved for processor-specific semantics.
+.TP
+.B STB_LOCAL
+Local symbols are not visible outside the object file containing their
+definition.
+Local symbols of the same name may exist in multiple files
+without interfering with each other.
+.TP
+.B STB_GLOBAL
+Global symbols are visible to all object files being combined.
+One file's
+definition of a global symbol will satisfy another file's undefined
+reference to the same symbol.
+.TP
+.B STB_WEAK
+Weak symbols resemble global symbols, but their definitions have lower
+precedence.
+.TP
+.BR STB_LOPROC ", " STB_HIPROC
+Values in the inclusive range
+.RB [ STB_LOPROC ,
+.BR STB_HIPROC ]
+are reserved for processor-specific semantics.
+.RE
+.IP
+There are macros for packing and unpacking the binding and type fields:
+.RS
+.TP
+.BR ELF32_ST_BIND( \fIinfo\fP ) ", " ELF64_ST_BIND( \fIinfo\fP )
+Extract a binding from an
+.I st_info
+value.
+.TP
+.BR ELF32_ST_TYPE( \fIinfo ) ", " ELF64_ST_TYPE( \fIinfo\fP )
+Extract a type from an
+.I st_info
+value.
+.TP
+.BR ELF32_ST_INFO( \fIbind\fP ", " \fItype\fP ) ", " \
+ELF64_ST_INFO( \fIbind\fP ", " \fItype\fP )
+Convert a binding and a type into an
+.I st_info
+value.
+.RE
+.TP
+.I st_other
+This member defines the symbol visibility.
+.RS
+.TP
+.PD 0
+.B STV_DEFAULT
+Default symbol visibility rules.
+Global and weak symbols are available to other modules;
+references in the local module can be interposed
+by definitions in other modules.
+.TP
+.B STV_INTERNAL
+Processor-specific hidden class.
+.TP
+.B STV_HIDDEN
+Symbol is unavailable to other modules;
+references in the local module always resolve to the local symbol
+(i.e., the symbol can't be interposed by definitions in other modules).
+.TP
+.B STV_PROTECTED
+Symbol is available to other modules,
+but references in the local module always resolve to the local symbol.
+.PD
+.PP
+There are macros for extracting the visibility type:
+.PP
+.BR ELF32_ST_VISIBILITY (other)
+or
+.BR ELF64_ST_VISIBILITY (other)
+.RE
+.TP
+.I st_shndx
+Every symbol table entry is
+"defined"
+in relation to some section.
+This member holds the relevant section
+header table index.
+.\"
+.SS Relocation entries (Rel & Rela)
+Relocation is the process of connecting symbolic references with
+symbolic definitions.
+Relocatable files must have information that
+describes how to modify their section contents, thus allowing executable
+and shared object files to hold the right information for a process's
+program image.
+Relocation entries are these data.
+.PP
+Relocation structures that do not need an addend:
+.PP
+.in +4n
+.EX
+typedef struct {
+    Elf32_Addr r_offset;
+    uint32_t   r_info;
+} Elf32_Rel;
+.EE
+.in
+.PP
+.in +4n
+.EX
+typedef struct {
+    Elf64_Addr r_offset;
+    uint64_t   r_info;
+} Elf64_Rel;
+.EE
+.in
+.PP
+Relocation structures that need an addend:
+.PP
+.in +4n
+.EX
+typedef struct {
+    Elf32_Addr r_offset;
+    uint32_t   r_info;
+    int32_t    r_addend;
+} Elf32_Rela;
+.EE
+.in
+.PP
+.in +4n
+.EX
+typedef struct {
+    Elf64_Addr r_offset;
+    uint64_t   r_info;
+    int64_t    r_addend;
+} Elf64_Rela;
+.EE
+.in
+.TP
+.I r_offset
+This member gives the location at which to apply the relocation action.
+For a relocatable file, the value is the byte offset from the beginning
+of the section to the storage unit affected by the relocation.
+For an
+executable file or shared object, the value is the virtual address of
+the storage unit affected by the relocation.
+.TP
+.I r_info
+This member gives both the symbol table index with respect to which the
+relocation must be made and the type of relocation to apply.
+Relocation
+types are processor-specific.
+When the text refers to a relocation
+entry's relocation type or symbol table index, it means the result of
+applying
+.B ELF[32|64]_R_TYPE
+or
+.BR ELF[32|64]_R_SYM ,
+respectively, to the entry's
+.I r_info
+member.
+.TP
+.I r_addend
+This member specifies a constant addend used to compute the value to be
+stored into the relocatable field.
+.\"
+.SS Dynamic tags (Dyn)
+The
+.I .dynamic
+section contains a series of structures that hold relevant
+dynamic linking information.
+The
+.I d_tag
+member controls the interpretation
+of
+.IR d_un .
+.PP
+.in +4n
+.EX
+typedef struct {
+    Elf32_Sword    d_tag;
+    union {
+        Elf32_Word d_val;
+        Elf32_Addr d_ptr;
+    } d_un;
+} Elf32_Dyn;
+extern Elf32_Dyn _DYNAMIC[];
+.EE
+.in
+.PP
+.in +4n
+.EX
+typedef struct {
+    Elf64_Sxword    d_tag;
+    union {
+        Elf64_Xword d_val;
+        Elf64_Addr  d_ptr;
+    } d_un;
+} Elf64_Dyn;
+extern Elf64_Dyn _DYNAMIC[];
+.EE
+.in
+.TP
+.I d_tag
+This member may have any of the following values:
+.RS
+.TP 12
+.B DT_NULL
+Marks end of dynamic section
+.TP
+.B DT_NEEDED
+String table offset to name of a needed library
+.TP
+.B DT_PLTRELSZ
+Size in bytes of PLT relocation entries
+.TP
+.B DT_PLTGOT
+Address of PLT and/or GOT
+.TP
+.B DT_HASH
+Address of symbol hash table
+.TP
+.B DT_STRTAB
+Address of string table
+.TP
+.B DT_SYMTAB
+Address of symbol table
+.TP
+.B DT_RELA
+Address of Rela relocation table
+.TP
+.B DT_RELASZ
+Size in bytes of the Rela relocation table
+.TP
+.B DT_RELAENT
+Size in bytes of a Rela relocation table entry
+.TP
+.B DT_STRSZ
+Size in bytes of string table
+.TP
+.B DT_SYMENT
+Size in bytes of a symbol table entry
+.TP
+.B DT_INIT
+Address of the initialization function
+.TP
+.B DT_FINI
+Address of the termination function
+.TP
+.B DT_SONAME
+String table offset to name of shared object
+.TP
+.B DT_RPATH
+String table offset to library search path (deprecated)
+.TP
+.B DT_SYMBOLIC
+Alert linker to search this shared object before the executable for symbols
+.TP
+.B DT_REL
+Address of Rel relocation table
+.TP
+.B DT_RELSZ
+Size in bytes of Rel relocation table
+.TP
+.B DT_RELENT
+Size in bytes of a Rel table entry
+.TP
+.B DT_PLTREL
+Type of relocation entry to which the PLT refers (Rela or Rel)
+.TP
+.B DT_DEBUG
+Undefined use for debugging
+.TP
+.B DT_TEXTREL
+Absence of this entry indicates that no relocation entries should
+apply to a nonwritable segment
+.TP
+.B DT_JMPREL
+Address of relocation entries associated solely with the PLT
+.TP
+.B DT_BIND_NOW
+Instruct dynamic linker to process all relocations before
+transferring control to the executable
+.TP
+.B DT_RUNPATH
+String table offset to library search path
+.TP
+.BR DT_LOPROC ", " DT_HIPROC
+Values in the inclusive range
+.RB [ DT_LOPROC ,
+.BR DT_HIPROC ]
+are reserved for processor-specific semantics
+.RE
+.TP
+.I d_val
+This member represents integer values with various interpretations.
+.TP
+.I d_ptr
+This member represents program virtual addresses.
+When interpreting
+these addresses, the actual address should be computed based on the
+original file value and memory base address.
+Files do not contain
+relocation entries to fixup these addresses.
+.TP
+.I _DYNAMIC
+Array containing all the dynamic structures in the
+.I .dynamic
+section.
+This is automatically populated by the linker.
+.\" GABI ELF Reference for Note Sections:
+.\" http://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section
+.\"
+.\" Note that it implies the sizes and alignments of notes depend on the ELF
+.\" size (e.g. 32-bit ELFs have three 4-byte words and use 4-byte alignment
+.\" while 64-bit ELFs use 8-byte words & alignment), but that is not the case
+.\" in the real world.  Notes always have three 4-byte words as can be seen
+.\" in the source links below (remember that Elf64_Word is a 32-bit quantity).
+.\" glibc:    https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/elf.h;h=9e59b3275917549af0cebe1f2de9ded3b7b10bf2#l1173
+.\" binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=binutils/readelf.c;h=274ddd17266aef6e4ad1f67af8a13a21500ff2af#l15943
+.\" Linux:    https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/elf.h?h=v4.8#n422
+.\" Solaris:  https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-18048.html
+.\" FreeBSD:  https://svnweb.freebsd.org/base/head/sys/sys/elf_common.h?revision=303677&view=markup#l33
+.\" NetBSD:   https://www.netbsd.org/docs/kernel/elf-notes.html
+.\" OpenBSD:  https://github.com/openbsd/src/blob/master/sys/sys/exec_elf.h#L533
+.\"
+.SS Notes (Nhdr)
+ELF notes allow for appending arbitrary information for the system to use.
+They are largely used by core files
+.RI ( e_type
+of
+.BR ET_CORE ),
+but many projects define their own set of extensions.
+For example,
+the GNU tool chain uses ELF notes to pass information from
+the linker to the C library.
+.PP
+Note sections contain a series of notes (see the
+.I struct
+definitions below).
+Each note is followed by the name field (whose length is defined in
+\fIn_namesz\fR) and then by the descriptor field (whose length is defined in
+\fIn_descsz\fR) and whose starting address has a 4 byte alignment.
+Neither field is defined in the note struct due to their arbitrary lengths.
+.PP
+An example for parsing out two consecutive notes should clarify their layout
+in memory:
+.PP
+.in +4n
+.EX
+void *memory, *name, *desc;
+Elf64_Nhdr *note, *next_note;
+\&
+/* The buffer is pointing to the start of the section/segment. */
+note = memory;
+\&
+/* If the name is defined, it follows the note. */
+name = note\->n_namesz == 0 ? NULL : memory + sizeof(*note);
+\&
+/* If the descriptor is defined, it follows the name
+   (with alignment). */
+\&
+desc = note\->n_descsz == 0 ? NULL :
+       memory + sizeof(*note) + ALIGN_UP(note\->n_namesz, 4);
+\&
+/* The next note follows both (with alignment). */
+next_note = memory + sizeof(*note) +
+                     ALIGN_UP(note\->n_namesz, 4) +
+                     ALIGN_UP(note\->n_descsz, 4);
+.EE
+.in
+.PP
+Keep in mind that the interpretation of
+.I n_type
+depends on the namespace defined by the
+.I n_namesz
+field.
+If the
+.I n_namesz
+field is not set (e.g., is 0), then there are two sets of notes:
+one for core files and one for all other ELF types.
+If the namespace is unknown, then tools will usually fallback to these sets
+of notes as well.
+.PP
+.in +4n
+.EX
+typedef struct {
+    Elf32_Word n_namesz;
+    Elf32_Word n_descsz;
+    Elf32_Word n_type;
+} Elf32_Nhdr;
+.EE
+.in
+.PP
+.in +4n
+.EX
+typedef struct {
+    Elf64_Word n_namesz;
+    Elf64_Word n_descsz;
+    Elf64_Word n_type;
+} Elf64_Nhdr;
+.EE
+.in
+.TP
+.I n_namesz
+The length of the name field in bytes.
+The contents will immediately follow this note in memory.
+The name is null terminated.
+For example, if the name is "GNU", then
+.I n_namesz
+will be set to 4.
+.TP
+.I n_descsz
+The length of the descriptor field in bytes.
+The contents will immediately follow the name field in memory.
+.TP
+.I n_type
+Depending on the value of the name field, this member may have any of the
+following values:
+.RS
+.TP 5
+.B Core files (e_type = ET_CORE)
+Notes used by all core files.
+These are highly operating system or architecture specific and often require
+close coordination with kernels, C libraries, and debuggers.
+These are used when the namespace is the default (i.e.,
+.I n_namesz
+will be set to 0), or a fallback when the namespace is unknown.
+.RS
+.TP 21
+.PD 0
+.B NT_PRSTATUS
+prstatus struct
+.TP
+.B NT_FPREGSET
+fpregset struct
+.TP
+.B NT_PRPSINFO
+prpsinfo struct
+.TP
+.B NT_PRXREG
+prxregset struct
+.TP
+.B NT_TASKSTRUCT
+task structure
+.TP
+.B NT_PLATFORM
+String from sysinfo(SI_PLATFORM)
+.TP
+.B NT_AUXV
+auxv array
+.TP
+.B NT_GWINDOWS
+gwindows struct
+.TP
+.B NT_ASRS
+asrset struct
+.TP
+.B NT_PSTATUS
+pstatus struct
+.TP
+.B NT_PSINFO
+psinfo struct
+.TP
+.B NT_PRCRED
+prcred struct
+.TP
+.B NT_UTSNAME
+utsname struct
+.TP
+.B NT_LWPSTATUS
+lwpstatus struct
+.TP
+.B NT_LWPSINFO
+lwpinfo struct
+.TP
+.B NT_PRFPXREG
+fprxregset struct
+.TP
+.B NT_SIGINFO
+siginfo_t (size might increase over time)
+.TP
+.B NT_FILE
+Contains information about mapped files
+.TP
+.B NT_PRXFPREG
+user_fxsr_struct
+.TP
+.B NT_PPC_VMX
+PowerPC Altivec/VMX registers
+.TP
+.B NT_PPC_SPE
+PowerPC SPE/EVR registers
+.TP
+.B NT_PPC_VSX
+PowerPC VSX registers
+.TP
+.B NT_386_TLS
+i386 TLS slots (struct user_desc)
+.TP
+.B NT_386_IOPERM
+x86 io permission bitmap (1=deny)
+.TP
+.B NT_X86_XSTATE
+x86 extended state using xsave
+.TP
+.B NT_S390_HIGH_GPRS
+s390 upper register halves
+.TP
+.B NT_S390_TIMER
+s390 timer register
+.TP
+.B NT_S390_TODCMP
+s390 time-of-day (TOD) clock comparator register
+.TP
+.B NT_S390_TODPREG
+s390 time-of-day (TOD) programmable register
+.TP
+.B NT_S390_CTRS
+s390 control registers
+.TP
+.B NT_S390_PREFIX
+s390 prefix register
+.TP
+.B NT_S390_LAST_BREAK
+s390 breaking event address
+.TP
+.B NT_S390_SYSTEM_CALL
+s390 system call restart data
+.TP
+.B NT_S390_TDB
+s390 transaction diagnostic block
+.TP
+.B NT_ARM_VFP
+ARM VFP/NEON registers
+.TP
+.B NT_ARM_TLS
+ARM TLS register
+.TP
+.B NT_ARM_HW_BREAK
+ARM hardware breakpoint registers
+.TP
+.B NT_ARM_HW_WATCH
+ARM hardware watchpoint registers
+.TP
+.B NT_ARM_SYSTEM_CALL
+ARM system call number
+.PD
+.RE
+.TP
+.B n_name = GNU
+Extensions used by the GNU tool chain.
+.RS
+.TP
+.B NT_GNU_ABI_TAG
+Operating system (OS) ABI information.
+The desc field will be 4 words:
+.IP
+.PD 0
+.RS
+.IP [0] 5
+OS descriptor
+(\fBELF_NOTE_OS_LINUX\fR, \fBELF_NOTE_OS_GNU\fR, and so on)`
+.IP [1]
+major version of the ABI
+.IP [2]
+minor version of the ABI
+.IP [3]
+subminor version of the ABI
+.RE
+.PD
+.TP
+.B NT_GNU_HWCAP
+Synthetic hwcap information.
+The desc field begins with two words:
+.IP
+.PD 0
+.RS
+.IP [0] 5
+number of entries
+.IP [1]
+bit mask of enabled entries
+.RE
+.PD
+.IP
+Then follow variable-length entries, one byte followed by a null-terminated
+hwcap name string.
+The byte gives the bit number to test if enabled, (1U << bit) & bit mask.
+.TP
+.B NT_GNU_BUILD_ID
+Unique build ID as generated by the GNU
+.BR ld (1)
+.B \-\-build\-id
+option.
+The desc consists of any nonzero number of bytes.
+.TP
+.B NT_GNU_GOLD_VERSION
+The desc contains the GNU Gold linker version used.
+.RE
+.TP
+.B Default/unknown namespace (e_type != ET_CORE)
+These are used when the namespace is the default (i.e.,
+.I n_namesz
+will be set to 0), or a fallback when the namespace is unknown.
+.RS
+.TP 12
+.PD 0
+.B NT_VERSION
+A version string of some sort.
+.TP
+.B NT_ARCH
+Architecture information.
+.PD
+.RE
+.RE
+.SH NOTES
+.\" OpenBSD
+.\" ELF support first appeared in
+.\" OpenBSD 1.2,
+.\" although not all supported platforms use it as the native
+.\" binary file format.
+ELF first appeared in
+System V.
+The ELF format is an adopted standard.
+.PP
+The extensions for
+.IR e_phnum ,
+.IR e_shnum ,
+and
+.I e_shstrndx
+respectively are
+Linux extensions.
+Sun, BSD, and AMD64 also support them; for further information,
+look under SEE ALSO.
+.\" .SH AUTHORS
+.\" The original version of this manual page was written by
+.\" .An Jeroen Ruigrok van der Werven
+.\" .Aq asmodai@FreeBSD.org
+.\" with inspiration from BSDi's
+.\" .Bsx
+.\" .Nm elf
+.\" man page.
+.SH SEE ALSO
+.BR as (1),
+.BR elfedit (1),
+.BR gdb (1),
+.BR ld (1),
+.BR nm (1),
+.BR objcopy (1),
+.BR objdump (1),
+.BR patchelf (1),
+.BR readelf (1),
+.BR size (1),
+.BR strings (1),
+.BR strip (1),
+.BR execve (2),
+.BR dl_iterate_phdr (3),
+.BR core (5),
+.BR ld.so (8)
+.PP
+Hewlett-Packard,
+.IR "Elf-64 Object File Format" .
+.PP
+Santa Cruz Operation,
+.IR "System V Application Binary Interface" .
+.PP
+UNIX System Laboratories,
+"Object Files",
+.IR "Executable and Linking Format (ELF)" .
+.PP
+Sun Microsystems,
+.IR "Linker and Libraries Guide" .
+.PP
+AMD64 ABI Draft,
+.IR "System V Application Binary Interface AMD64 Architecture Processor Supplement" .