object-files.tex

\chapter{Object Files}

\section{Sections}

The following section types are defined.

\begin{table}[H]
\Hrule
  \caption{Section types}
  \begin{center}
    \begin{tabular}[t]{l|l}
      \multicolumn{1}{c}{Name} & \multicolumn{1}{c}{Value} \\
      \hline
      \texttt{SHT_GNU_INCREMENTAL_INPUTS} & \texttt{0x6fff4700} \\
      \texttt{SHT_LLVM_ODRTAB} & \texttt{0x6fff4c00} \\
      \texttt{SHT_GNU_ATTRIBUTES} & \texttt{0x6ffffff5} \\
      \texttt{SHT_GNU_HASH} & \texttt{0x6ffffff6} \\
      \texttt{SHT_GNU_LIBLIST} & \texttt{0x6ffffff7} \\
  \end{tabular}
 \end{center}
\Hrule
\end{table}

\begin{description}
  \item[SHT_GNU_INCREMENTAL_INPUTS] Incremental build data.
  \item[SHT_LLVM_ODRTAB] LLVM ODR table.
  \item[SHT_GNU_ATTRIBUTES] Object attributes.
  \item[SHT_GNU_HASH] GNU style symbol hash table.
  \item[SHT_GNU_LIBLIST] List of prelink dependencies.
\end{description}

The section type range \texttt{0x6fff4c00} to \texttt{0x6fff4cff}
is reserved for LLVM.

\subsection{Special Sections}

\begin{table}[H]
\Hrule
  \caption{Special sections}
  \begin{center}
    \begin{tabular}[t]{l|l|l}
      \multicolumn{1}{c}{Name} & \multicolumn{1}{c}{Type}
       & \multicolumn{1}{c}{Attributes} \\
      \hline
      \texttt{.eh_frame} & \texttt{SHT_PROGBITS} & \texttt{SHF_ALLOC} \\
      \texttt{.eh_frame_hdr} & \texttt{SHT_PROGBITS} & \texttt{SHF_ALLOC} \\
      \texttt{.note.ABI-tag} & \texttt{SHT_NOTE} & \texttt{SHF_ALLOC} \\
      \texttt{.note.gnu.build-id} & \texttt{SHT_NOTE} & \texttt{SHF_ALLOC} \\
      \texttt{.note.gnu.property} & \texttt{SHT_NOTE} & \texttt{SHF_ALLOC} \\
      \texttt{.sdata} & \texttt{SHT_PROGBITS} & \texttt{SHF_ALLOC+SHF_WRITE} \\
      \texttt{.sbss} & \texttt{SHT_NOBITS} & \texttt{SHF_ALLOC+SHF_WRITE} \\
      \texttt{.lrodata} & \texttt{SHT_PROGBITS} & \texttt{SHF_ALLOC} \\
      \texttt{.ldata} & \texttt{SHT_PROGBITS} & \texttt{SHF_ALLOC+SHF_WRITE} \\
      \texttt{.lbss} & \texttt{SHT_NOBITS} & \texttt{SHF_ALLOC+SHF_WRITE} \\
      \texttt{.data.rel.ro} & \texttt{SHT_PROGBITS} & \texttt{SHF_ALLOC+SHF_WRITE} \\
      \texttt{.data.rel.local.ro} & \texttt{SHT_PROGBITS} & \texttt{SHF_ALLOC+SHF_WRITE}
    \end{tabular}
  \end{center}
\Hrule
\end{table}

\begin{description}
 \item[.eh_frame] This section holds the unwind function table.  The
   contents are described in Section~\ref{sec_eh_frame} of this document.
 \item[.eh_frame_hdr] This section holds information about
   \code{.eh_frame} section. The contents are described in
   Section~\ref{sec_eh_frame_hdr} of this document.
 \item[.note.ABI-tag] This section holds an ABI  note.  The contents are
   described in Section~\ref{sec_abi_tag} of this document.
 \item[.note.gnu.build-id] This section holds a build ID note.  The
   contents are described in Section~\ref{sec_build_id} of this document.
 \item[.note.gnu.property] This section holds a program property note.
   The contents are described in Section~\ref{sec_property} of this
   document.
 \item[.sdata] This section holds small initialized data that
   contribute to the program's memory image.
 \item[.sbss] This section holds small uninitialized data that
   contribute to the program's memory image.  By definition, the system
   initializes the data with zeros when the program begins to run.
 \item[.lrodata] This section holds large read-only data that typically
   contribute to a non-writable segment in the process image.
 \item[.ldata] This section holds large initialized data that
   contribute to the program's memory image.
 \item[.lbss] This section holds large uninitialized data that
   contribute to the program's memory image.  By definition, the system
   initializes the data with zeros when the program begins to run.
 \item[.data.rel.ro] This section holds read-only data that typically
   contribute to a writable segment in the process image which becomes
   non-writable after relocation is completed.
 \item[.data.rel.local.ro] This section holds read-only data that
   typically contribute to a writable segment in the process image
   which becomes non-writable after relocation is completed.  All
   relocations contained in this section must be to local objects.
\end{description}

\subsection{EH\_FRAME section}
\label{sec_eh_frame}

The call frame information needed for unwinding the stack is output into
one section named
\code{.eh_frame}.  An \code{.eh_frame} section consists of one or more
subsections. Each subsection contains a CIE (Common Information Entry)
followed by varying number of FDEs (Frame Descriptor Entry). A FDE
corresponds to an explicit or compiler generated function in a
compilation unit, all FDEs can access the CIE that begins their
subsection for data.  If the code for a function is not one contiguous
block, there will be a separate FDE for each contiguous sub-piece.

If an object file contains C++ template instantiations there shall be
a separate CIE immediately preceding each FDE corresponding to an
instantiation.

Using the preferred encoding specified below, the \code{.eh_frame} section can
be entirely resolved at link time and thus can become part of the
text segment.

\code{EH_PE} encoding below refers to the pointer encoding as specified in
Section \texttt{DWARF Exception Header Encoding} of Linux Standard Base
Core Specification.

\begin{table}[H]
\Hrule
\caption{Common Information Entry (CIE)}
\label{format-cie}
\begin{center}
\begin{tabular}{p{7em}|l|p{17em}}
  \multicolumn{1}{c}{Field}
         & \multicolumn{1}{c}{Length (byte)}
         & \multicolumn{1}{c}{Description} \\ \hline
  Length & 4 & Length of the CIE (not including this 4-byte field) \\
  CIE id & 4 & Value 0 for \code{.eh_frame} (used to distinguish CIEs and
		  FDEs when scanning the section) \\
  Version & 1 & Value One (1) \\
  CIE Augmentation String & string & Null-terminated string with legal
     values being "" or 'z' optionally followed by single occurrances of
     'P', 'L', or 'R' in any order.  The presence of character(s) in the
     string dictates the content of field 8, the Augmentation Section.  Each
     character has one or two associated operands in the AS (see
     table~\ref{format-cieaug} for which ones).  Operand order
     depends on position in the string ('z' must be first). \\
  Code Align Factor & uleb128 & To be multiplied with the
    "Advance Location" instructions in the Call Frame Instructions \\
  Data Align Factor & sleb128 & To be multiplied with all offsets
                                in the Call Frame Instructions \\
  Ret Address Reg & 1/uleb128 &  A "virtual" register representation
                                 of the return address. In Dwarf V2,
			         this is a byte, otherwise it is
			         uleb128. It is a byte in gcc 3.3.x \\
  Optional CIE Augmentation Section & varying & Present if Augmentation
                     String in Augmentation Section field 4 is not 0.
		     See table~\ref{format-cieaug} for the content. \\
  Optional Call Frame Instructions & varying & \\
\hline
    \end{tabular}
  \end{center}
\Hrule
\end{table}

\begin{table}[H]
\Hrule
\caption{CIE Augmentation Section Content}
\label{format-cieaug}
\begin{center}
\begin{tabular}{l|p{6em}|l|p{16em}}
  \multicolumn{1}{c}{Char}
         & \multicolumn{1}{c}{Operands}
         & \multicolumn{1}{c}{Length (byte)}
         & \multicolumn{1}{c}{Description} \\ \hline
  z & size & uleb128 & Length of the remainder of the
                                        Augmentation Section \\
  P & personality_enc & 1 & Encoding specifier - preferred
                            value is a pc-relative, signed
                            4-byte \\
    & personality routine & (encoded) & Encoded pointer to personality
                                        routine (actually to the PLT
                                        entry for the personality
                                        routine) \\
  R & code_enc & 1 & Non-default encoding for the
                     code-pointers (FDE members
                     \code{initial_location} and \code{address_range}
                     and the operand for \code{DW_CFA_set_loc})
                     - preferred value is pc-relative,
                     signed 4-byte \\
  L & lsda_enc & 1 & FDE augmentation bodies may contain
		     LSDA pointers. If so they are encoded
		     as specified here -
		     preferred value is pc-relative, signed 4-byte possibly
		     indirect thru a GOT entry \\
\hline
    \end{tabular}
  \end{center}
\Hrule
\end{table}

\begin{table}[H]
\Hrule
\caption{Frame Descriptor Entry (FDE)}
\label{format-fde}
\begin{center}
\begin{tabular}{p{7em}|l|p{17em}}
  \multicolumn{1}{c}{Field}
         & \multicolumn{1}{c}{Length (byte)}
         & \multicolumn{1}{c}{Description} \\ \hline
  Length & 4 & Length of the FDE (not including this 4-byte field) \\
  CIE pointer & 4 & Distance from this field to the
		    nearest preceding CIE (the value is subtracted from the
		    current address). This value can never be zero and thus can
		    be used to distinguish CIE's and FDE's when scanning the
		    \code{.eh_frame} section \\
  Initial Location & var & Reference to the function code
                           corresponding to this FDE.
                           If 'R' is missing from the CIE
                           Augmentation String, the field is an
                           8-byte absolute pointer. Otherwise,
                           the corresponding \code{EH_PE} encoding in the
                           CIE Augmentation Section is used to
                           interpret the reference \\
  Address Range & var & Size of the function code corresponding
                       to this FDE.
                       If 'R' is missing from the CIE
                       Augmentation String, the field is an
                       8-byte unsigned number. Otherwise,
                       the size is determined by the
                       corresponding \code{EH_PE} encoding in the
                       CIE Augmentation Section (the
                       value is always absolute) \\
  Optional FDE Augmentation Section & var & Present if CIE Augmentation
                     String is non-empty.
		     See table~\ref{format-fdeaug} for the content. \\
  Optional Call Frame Instructions & var & \\
\hline
    \end{tabular}
  \end{center}
\Hrule
\end{table}

\begin{table}[H]
\Hrule
\caption{FDE Augmentation Section Content}
\label{format-fdeaug}
\begin{center}
\begin{tabular}{l|p{6em}|l|p{16em}}
  \multicolumn{1}{c}{Char}
         & \multicolumn{1}{c}{Operands}
         & \multicolumn{1}{c}{Length (byte)}
         & \multicolumn{1}{c}{Description} \\ \hline
  z & length & uleb128 & Length of the remainder of the
                                        Augmentation Section \\
  L & LSDA & var & LSDA pointer, encoded in the
                   format specified by the
                   corresponding operand in the CIE's
                   augmentation body. (only present if length > 0). \\
\hline
    \end{tabular}
  \end{center}
\Hrule
\end{table}
The existence and size of the optional call frame instruction area must
be computed
based on the overall size and the offset reached while scanning the
preceding fields of the CIE or FDE.

The overall size of a \code{.eh_frame} section is given in the ELF section
header.  The only way to determine the number of entries is to scan
the section until the end, counting entries as they are encountered.

\subsection{EH\_FRAME\_HDR section}
\label{sec_eh_frame_hdr}

\code{.eh_frame_hdr} section contains information about \code{.eh_frame}
section for optimizing stack unwinding.

\begin{table}[H]
\Hrule
 \caption{\code{.eh_frame_hdr} Section Format}
 \label{format-eh_frame_hdr}
 \begin{center}
  \begin{tabular}[t]{l|l|l}
   \multicolumn{1}{c}{Encoding}
     & \multicolumn{1}{c}{Field}
       & \multicolumn{1}{c}{Required} \\
   \hline
   \texttt{unsigned byte} & \texttt{version} & \texttt{Yes} \\
   \texttt{unsigned byte} & \texttt{eh_frame_ptr_enc} & \texttt{Yes}\\
   \texttt{unsigned byte} & \texttt{fde_count_enc} & \texttt{Yes} \\
   \texttt{unsigned byte} & \texttt{table_enc} & \texttt{Yes} \\
   \texttt{[encoded]} & \texttt{eh_frame_ptr} & \texttt{No} \\
   \texttt{[encoded]} & \texttt{fde_count} & \texttt{No} \\
    & \texttt{binary search table} & \texttt{No} \\
  \end{tabular}
 \end{center}
\Hrule
\end{table}

\begin{description}
 \item[version] Version of \code{.eh_frame_hdr} section format.  It
   should be 1.
 \item[eh_frame_ptr_enc] \code{EH_PE} encoding of pointer to start of
   \code{.eh_frame} section.
 \item[fde_count_enc] \code{EH_PE} encoding of total FDE count number.
   \code{DW_EH_PE_omit} if there is no \code{binary search table}.
 \item[table_enc] \code{EH_PE} encoding of \code{binary search table}.
   \code{DW_EH_PE_omit} if there is no \code{binary search table}.
 \item[eh_frame_ptr] Pointer to start of \code{.eh_frame} section.
 \item[fde_count] Total number of FDEs in \code{.eh_frame}
   section.
 \item[binary search table] A binary search table containing
   \code{fde_count} entries. Each entry consists of FDE initial location
   and address.  The entries are sorted in the increasing order by FDE
   initial location value.
\end{description}

\subsection{\code{.note.gnu.build-id} section}
\label{sec_build_id}

\code{.note.gnu.build-id} section contains a build ID note which is
unique among the set of meaningful contents for ELF files and identical
when the output file would otherwise have been identical.  It can be
merged with other \code{SHT_NOTE} sections.

\begin{table}[H]
\Hrule
 \caption{The Build ID Note Format}
 \label{format-build_id}
 \begin{center}
  \begin{tabular}[t]{l|l|l}
   \multicolumn{1}{c}{Field}
     & \multicolumn{1}{c}{Length}
       & \multicolumn{1}{c}{Contents} \\
   \hline
   \texttt{n_namsz} & \texttt{4} & \texttt{4} \\
   \texttt{n_descsz} & \texttt{4} & The note descriptor size \\
   \texttt{n_type} & \texttt{4} & \texttt{NT_GNU_BUILD_ID} \\
   \texttt{n_name} & \texttt{4} & \texttt{GNU} \\
   \texttt{n_desc} & \texttt{n_descsz} & The build ID \\
  \end{tabular}
 \end{center}
\Hrule
\end{table}

\begin{description}
 \item[n_namsz] Size of the \code{n_name} field.  A 4-byte integer in the
   format of the target processor.  It should be 4.
 \item[n_descsz] Size of the \code{n_desc} field.  A 4-byte integer in the
   format of the target processor.
 \item[n_type] Type of the note descriptor.  A 4-byte integer in the format
   of the target processor.  It should be \code{NT_GNU_BUILD_ID}.
 \item[n_name] Owner of the build ID note.  A null-terminated character
   string.  It should be \code{GNU}.
 \item[n_desc] The note descriptor.  The first \code{n_descsz} bytes in
   \code{n_desc} is the build ID.
\end{description}

\subsection{\code{.note.gnu.property} section}
\label{sec_property}

\code{.note.gnu.property} section contains a program property note which
describes special handling requirements for linker and run-time loader.
It can be merged with other \code{SHT_NOTE} sections.

\begin{table}[H]
\Hrule
 \caption{The Program Property Note Format}
 \label{format-property}
 \begin{center}
  \begin{tabular}[t]{l|l|l}
   \multicolumn{1}{c}{Field}
     & \multicolumn{1}{c}{Length}
       & \multicolumn{1}{c}{Contents} \\
   \hline
   \texttt{n_namsz} & \texttt{4} & \texttt{4} \\
   \texttt{n_descsz} & \texttt{4} & The note descriptor size \\
   \texttt{n_type} & \texttt{4} & \texttt{NT_GNU_PROPERTY_TYPE_0} \\
   \texttt{n_name} & \texttt{4} & \texttt{GNU} \\
   \texttt{n_desc} & \texttt{n_descsz} & The program property array \\
  \end{tabular}
 \end{center}
\Hrule
\end{table}

\begin{description}
 \item[n_namsz] Size of the \code{n_name} field.  A 4-byte integer in the
   format of the target processor.  It should be 4.
 \item[n_descsz] Size of the \code{n_desc} field.  A 4-byte integer in the
   format of the target processor.
 \item[n_type] Type of the note descriptor.  A 4-byte integer in the format
   of the target processor.  It should be \code{NT_GNU_PROPERTY_TYPE_0}.
 \item[n_name] Owner of the program property note.  A null-terminated
   character string.  It should be \code{GNU}.
 \item[n_desc] The note descriptor.  The first \code{n_descsz} bytes in
   \code{n_desc} is the program property array.
\end{description}

\subsubsection{The program property array}

Each array element represents one program property with type, data size
and data.  In 64-bit objects, each element is an array of 8-byte integers
in the format of the target processor.  In 32-bit objects, each element
is an array of 4-byte integers in the format of the target processor.
An array element has the following structure:

\begin{verbatim}
typedef struct {
  Elf_Word pr_type;
  Elf_Word pr_datasz;
  unsigned char pr_data[PR_DATASZ];
  unsigned char pr_padding[PR_PADDING];
} Elf_Prop;
\end{verbatim}

\begin{description}
 \item[pr_type] The type of program property.  A 4-byte integer in the
   format of the target processor.
 \item[pr_datasz] The size of the \code{pr_data} field.  A 4-byte
   integer in the format of the target processor.
 \item[pr_data] The program property descriptor which is aligned to 4
   bytes in 32-bit objects and 8 bytes in 64-bit objects.
 \item[pr_padding] The padding.  If necessary, it aligns the array
   element to 8 or 4-byte alignment (depending on whether the file is
   a 64-bit or 32-bit object).
 \item[PR_DATASZ] The value in the \code{pr_datasz} field.  A constant.
 \item[PR_PADDING] The size of the \code{pr_padding} field.  A constant.
\end{description}

The array elements are sorted by the program property type in ascending
order.

\subsubsection{Types of program properties}

The following program property types are defined:

\begin{table}[H]
\Hrule
  \caption{Program Property Types}
  \begin{center}
    \begin{tabular}[t]{l|l}
      \multicolumn{1}{c}{Name} & \multicolumn{1}{c}{Value} \\
      \hline
      \texttt{GNU_PROPERTY_STACK_SIZE} & \texttt{1} \\
      \texttt{GNU_PROPERTY_NO_COPY_ON_PROTECTED} & \texttt{2} \\
      \texttt{GNU_PROPERTY_LOPROC} & \texttt{0xc0000000} \\
      \texttt{GNU_PROPERTY_HIPROC} & \texttt{0xdfffffff} \\
      \texttt{GNU_PROPERTY_LOUSER} & \texttt{0xe0000000} \\
      \texttt{GNU_PROPERTY_HIUSER} & \texttt{0xffffffff} \\
    \end{tabular}
  \end{center}
\Hrule
\end{table}

\begin{description}
 \item[GNU_PROPERTY_STACK_SIZE]
   Its \code{pr_data} field contains a 4-byte integer in 32-bit objects
   and 8-byte integer in 64-bit objects, in the format of the target
   processor.  Linker should select the maximum value among all
   input relocatable objects and copy this property to the output.
   Run-time loader should raise the stack limit to the value specified
   in this property.
 \item[GNU_PROPERTY_NO_COPY_ON_PROTECTED]
   \begin{sloppypar}
   This indicates that there should be no copy relocations against
   protected data symbols.  If a relocatable object contains this
   property, linker should treat protected data symbol as defined
   locally at run-time and copy this property to the output share
   object.  Linker should add this property to the output share
   object if any protected symbol is expected to be defined locally
   at run-time.  Run-time loader should disallow copy relocations
   against protected data symbols defined in share objects with
   \code{GNU_PROPERTY_NO_COPY_ON_PROTECTED} property.  Its
   \code{PR_DATASZ} should be 0.
   \end{sloppypar}
 \item[GNU_PROPERTY_LOPROC through GNU_PROPERTY_HIPROC]
   Values in this inclusive range are reserved for processor-specific
   semantics.
 \item[GNU_PROPERTY_LOUSER through GNU_PROPERTY_HIUSER]
   Values in this inclusive range are reserved for application-specific
   semantics.
\end{description}

\subsection{\code{.note.ABI-tag} section}
\label{sec_abi_tag}

\code{.note.ABI-tag} section contains an ABI note which is used to
identify OS and version targeted.  It can be merged with other
\code{SHT_NOTE} sections.

\begin{table}[H]
\Hrule
 \caption{The ABI Tag Note Format}
 \label{format-abi_tag}
 \begin{center}
  \begin{tabular}[t]{l|l|l}
   \multicolumn{1}{c}{Field}
     & \multicolumn{1}{c}{Length}
       & \multicolumn{1}{c}{Contents} \\
   \hline
   \texttt{n_namsz} & \texttt{4} & \texttt{4} \\
   \texttt{n_descsz} & \texttt{4} & \texttt{16} \\
   \texttt{n_type} & \texttt{4} & \texttt{NT_GNU_ABI_TAG} \\
   \texttt{n_name} & \texttt{4} & \texttt{GNU} \\
   \texttt{n_desc} & \texttt{16} & The ABI tag\\
  \end{tabular}
 \end{center}
\Hrule
\end{table}

\begin{description}
 \item[n_namsz] Size of the \code{n_name} field.  A 4-byte integer in the
   format of the target processor.  It should be 4.
 \item[descsz] Size of the \code{n_desc} field.  It should be 16.
 \item[n_type] Type of the note descriptor.  A 4-byte integer in the format
   of the target processor.  It should be \code{NT_GNU_ABI_TAG}.
 \item[n_name] Owner of the build ID note.  A null-terminated character
   string.  It should be \code{GNU}.
 \item[n_desc] The note descriptor. Four 4-byte integers in the format of
   the target processor.  The first 4-byte integer should 0.  The second,
   third, and fourth 4-byte integers contain the earliest compatible
   kernel version.  For example, if the 3 integers are 2, 2, and 5, this
   signifies a 2.2.5 kernel.
\end{description}

\subsection{Alignment of Note Sections}

All entries in a \texttt{PT_NOTE} segment have the same alignment which
equals to the {\tt p_align} field in program header.

According to gABI, each note entry should be aligned to 4 bytes in
32-bit objects or 8 bytes in 64-bit objects.  But \code{.note.ABI-tag}
section (see Section~\ref{sec_abi_tag}) and \code{.note.gnu.build-id}
section (see Section~\ref{sec_build_id}) are aligned to 4 bytes in
both 32-bit and 64-bit objects.  Note parser should use {\tt p_align}
for note alignment, instead of assuming alignment based on ELF file class.

\section{Symbol Table}

\begin{table}[H]
\Hrule
  \caption{\xOS Specific Symbol Types}
  \label{ifunc}
  \begin{center}
    \begin{tabular}[t]{l|l}
      \multicolumn{1}{c}{Name} & \multicolumn{1}{c}{Value} \\
      \hline
      \texttt{STT_GNU_IFUNC} & \texttt{10}
    \end{tabular}
  \end{center}
\Hrule
\end{table}

\subsection{\texttt{STT_GNU_IFUNC} Symbol}

This symbol type is the same as \texttt{STT_FUNC} except that it always
points to a resolve function or piece of executable code which takes
no arguments and returns a function pointer.  If an \texttt{STT_GNU_IFUNC}
symbol is referred to by a relocation, then evaluation of that relocation
is delayed until load-time.  The value used in the relocation is the
function pointer returned by an invocation of the \texttt{STT_GNU_IFUNC}
symbol.

The purpose of the \texttt{STT_GNU_IFUNC} symbol type is to allow the
run-time to select between multiple versions of the implementation of
a specific function.  The selection made in general will take the
currently available hardware into account and select the most
appropriate version.

\subsubsection{Implementation Considerations}

The calling convention of the \texttt{STT_GNU_IFUNC} resolve
function, which takes no arguments and returns a function pointer,
should follow the processor-specific ABI. All rules for caller-saved
and callee-saved registers apply.

There are special considerations for GOT when PLT is required:

\begin{itemize}
\item All references to a \texttt{STT_GNU_IFUNC} symbol, including
function call and function pointer, should go through the PLT slot,
which jumps to the address stored in the GOT entry.  If the
\texttt{STT_GNU_IFUNC} symbol is locally defined, a processor-specific
\texttt{IRELATIVE} relocation should be applied to the GOT entry at load
time.  Otherwise, dynamic linker will lookup the symbol at the first
reference to the function and update the GOT entry.  This applies to all
usages of \texttt{STT_GNU_IFUNC} symbols in shared library, dynamic
executable and static executable.

Instead of branching to an \texttt{STT_GNU_IFUNC} symbol directly, calling
a function always branches to its PLT entry, which simply loads its GOTPLT
entry and branches to it.  Its GOTPLT entry has the real function address.

\item An \texttt{STT_GNU_IFUNC} symbol has an optional GOT entry for the
function pointer value of the symbol.  To load an \texttt{STT_GNU_IFUNC}
symbol function pointer value:

  \begin{itemize}
  \item Use its GOTPLT entry in a shared object if it is forced local or
        not dynamic.
  \item Use its GOTPLT entry in a non-shared object if pointer equality
        isn't needed.
  \item Use its GOTPLT entry in a position independent executable (PIE).
  \item Use its GOTPLT entry if no normal GOT, other than GOTPLT, is used.
  \item Otherwise use its GOT entry.  We only need to relocate its GOT
        entry in a shared object.
  \end{itemize}

\item We need dynamic relocation for \texttt{STT_GNU_IFUNC} symbol only
when there is a non-GOT reference in a shared object.

\item When a shared library references a \texttt{STT_GNU_IFUNC} symbol
defined in executable, the address of the resolved function may be used.
But in non-shared executable, the address of its GOTPLT entry may be used.
Pointer equality may not work correctly.  PIE should be used if pointer
equality is required.
\end{itemize}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: "abi"
%%% End: