-
Notifications
You must be signed in to change notification settings - Fork 2
/
object-files.tex
618 lines (556 loc) · 24.8 KB
/
object-files.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
\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: