pintos-os.org Git - pintos-anon/blob - specs/sysv-abi-update.html/ch5.dynamic.html

   1 <html>
   2 <title>Dynamic Linking</title><p>
   3 <h1>Dynamic Linking</h1><p>
   4 <a name=interpreter></a>
   5 <h2>Program Interpreter</h2><p>
   6 An executable file that participates in
   7 dynamic linking shall have one
   8 <code>PT_INTERP</code> program header element.
   9 During
  10 <code>exec</code>(BA_OS),
  11 the system retrieves a path name from the <code>PT_INTERP</code>
  12 segment and creates the initial process image from
  13 the interpreter file's segments. That is,
  14 instead of using the original executable file's
  15 segment images, the system composes a memory
  16 image for the interpreter.
  17 It then is the interpreter's responsibility to
  18 receive control from the system and provide an
  19 environment for the application program.
  20 <p>
  21 As ``Process Initialization'' in Chapter 3 of the
  22 processor supplement mentions,
  23 the interpreter receives control in one of two ways.
  24 First, it may receive a file descriptor
  25 to read the executable file, positioned at the beginning.
  26 It can use this file descriptor to read and/or map the executable
  27 file's segments into memory.
  28 Second, depending on the executable file format, the system
  29 may load the executable file into memory instead of giving the
  30 interpreter an open file descriptor.
  31 With the possible exception of the file descriptor,
  32 the interpreter's initial process state matches
  33 what the executable file would have received.
  34 The interpreter itself may not require a second interpreter.
  35 An interpreter may be either a shared object
  36 or an executable file.
  37 <ul>
  38 <p><li>
  39 A shared object (the normal case) is loaded as
  40 position-independent, with addresses that may vary
  41 from one process to another; the system creates its segments
  42 in the dynamic segment area used by <code>mmap</code>(KE_OS) and related services
  43 [See ``Virtual Address Space'' in Chapter 3 of the processor
  44 supplement].
  45 Consequently, a shared object interpreter typically will
  46 not conflict with the original executable file's
  47 original segment addresses.
  48 <p><li>
  49 An executable file may be loaded at fixed addresses;
  50 if so, the system creates its segments
  51 using the virtual addresses from the program header table.
  52 Consequently, an executable file interpreter's
  53 virtual addresses may collide with the
  54 first executable file; the interpreter is responsible
  55 for resolving conflicts.
  56 </ul>
  57 <a name=dynamic_linker></a>
  58 <h2>Dynamic Linker</h2>
  59 When building an executable file that uses dynamic linking,
  60 the link editor adds a program header element of type
  61 <code>PT_INTERP</code> to an executable file, telling the system to invoke
  62 the dynamic linker as the program interpreter.
  63 <hr>
  64 <img src=warning.gif alt="NOTE:">
  65 The locations of the system provided dynamic
  66 linkers are processor specific.
  67 <hr><p>
  68 <code>Exec</code>(BA_OS)
  69 and the dynamic linker cooperate to
  70 create the process image for the program, which entails
  71 the following actions:
  72 <ul>
  73 <p><li>
  74 Adding the executable file's memory segments to the process image;
  75 <p><li>
  76 Adding shared object memory segments to the process image;
  77 <p><li>
  78 Performing relocations for the executable file and its
  79 shared objects;
  80 <p><li>
  81 Closing the file descriptor that was used to read the executable file,
  82 if one was given to the dynamic linker;
  83 <p><li>
  84 Transferring control to the program, making it look as if
  85 the program had received control directly from
  86 <code>exec</code>(BA_OS).
  87 </ul>
  88 <p>
  89 The link editor also constructs various data
  90 that assist the dynamic linker
  91 for executable and shared object files.
  92 As shown above in
  93 <a href=ch5.pheader.html>``Program Header''</a>,
  94 this data resides
  95 in loadable segments, making them available during execution.
  96 (Once again, recall the exact segment contents are processor-specific.
  97 See the processor supplement for complete information).
  98 <ul>
  99 <p><li>
 100 A <code>.dynamic</code> section with type <code>SHT_DYNAMIC</code>
 101 holds various data.
 102 The structure residing at the
 103 beginning of the section holds the addresses
 104 of other dynamic linking information.
 105 <p><li>
 106 The <code>.hash</code> section with type <code>SHT_HASH</code>
 107 holds a symbol hash table.
 108 <p><li>
 109 The <code>.got</code> and <code>.plt</code> sections with type
 110 <code>SHT_PROGBITS</code>
 111 hold two separate tables:
 112 the global offset table and the procedure linkage table.
 113 Chapter 3 discusses how programs use the global offset table
 114 for position-independent code.
 115 Sections below explain how the dynamic linker uses
 116 and changes the tables to create memory images for object files.
 117 </ul>
 118 <p>
 119 Because every ABI-conforming program imports the basic system
 120 services from a shared object library [See ``System Library''
 121 in Chapter 6], the dynamic linker participates in every
 122 ABI-conforming program execution.
 123 <p>
 124 As
 125 `Program Loading'' explains in the processor supplement,
 126 shared objects may occupy
 127 virtual memory addresses that are different from the addresses recorded
 128 in the file's program header table.
 129 The dynamic linker relocates the memory image, updating
 130 absolute addresses before the application gains control.
 131 Although the absolute address values would be correct
 132 if the library were loaded at
 133 the addresses specified in the program header table, this normally
 134 is not the case.
 135 <p>
 136 If the process environment [see <code>exec</code>(BA_OS)]
 137 contains a variable named <code>LD_BIND_NOW</code>
 138 with a non-null value, the dynamic linker processes
 139 all relocations before transferring control to the program.
 140 For example, all the following environment entries
 141 would specify this behavior.
 142 <ul>
 143 <p><li>
 144 <code>LD_BIND_NOW=1</code>
 145 <p><li>
 146 <code>LD_BIND_NOW=on</code>
 147 <p><li>
 148 <code>LD_BIND_NOW=off</code>
 149 </ul>
 150 Otherwise, <code>LD_BIND_NOW</code> either
 151 does not occur in the environment or has a null value.
 152 The dynamic linker is permitted to evaluate procedure linkage table
 153 entries lazily, thus avoiding symbol resolution and relocation
 154 overhead for functions that are not called.
 155 See ``Procedure Linkage Table'' in this chapter of the processor
 156 supplement for more information.
 157 <a name=dynamic_section></a>
 158 <h2>Dynamic Section</h2><p>
 159 If an object file participates in dynamic linking,
 160 its program header table will have an element of type
 161 <code>PT_DYNAMIC</code>.
 162 This ``segment'' contains the <code>.dynamic</code> section.
 163 A special symbol, <code>_DYNAMIC</code>,
 164 labels the section, which contains
 165 an array of the following structures.
 166 <hr>
 167 <b>Figure 5-9: Dynamic Structure</b>
 168 <p>
 169 <pre>
 170 <code>
 171 typedef struct {
 172         Elf32_Sword     d_tag;
 173         union {
 174                 Elf32_Word      d_val;
 175                 Elf32_Addr      d_ptr;
 176         } d_un;
 177 } Elf32_Dyn;
 178
 179 extern Elf32_Dyn        _DYNAMIC[];
 180
 181 typedef struct {
 182         Elf64_Sxword    d_tag;
 183         union {
 184                 Elf64_Xword     d_val;
 185                 Elf64_Addr      d_ptr;
 186         } d_un;
 187 } Elf64_Dyn;
 188
 189 extern Elf64_Dyn        _DYNAMIC[];
 190 </code>
 191 </pre>
 192 <hr>
 193 <p>
 194 For each object with this type, <code>d_tag</code>
 195 controls the interpretation of <code>d_un</code>.
 196 <DL COMPACT>
 197 <p><dt><code>d_val</code><dd>
 198 These objects represent integer values with various
 199 interpretations.
 200 <p><dt><code>d_ptr</code><dd>
 201 These objects represent program virtual addresses.
 202 As mentioned previously, a file's virtual addresses
 203 might not match the memory virtual addresses during execution.
 204 When interpreting addresses contained in the dynamic
 205 structure, the dynamic linker computes actual addresses,
 206 based on the original file value and the memory base address.
 207 For consistency, files do <i>not</i>
 208 contain relocation entries to ``correct'' addresses in the dynamic
 209 structure.
 210 </dl>
 211 <p>
 212 <a name=tag_encodings></a>
 213 To make it simpler for tools to interpret the contents of
 214 dynamic section entries, the value of each tag, except for those in
 215 two special compatibility ranges,
 216 will determine the interpretation of the <code>d_un</code>
 217 union.  A tag whose value is an even number
 218 indicates a dynamic section entry that uses <code>d_ptr</code>.
 219 A tag whose value is an odd number indicates a dynamic section entry
 220 that uses <code>d_val</code> or that uses neither <code>d_ptr</code>
 221 nor <code>d_val</code>.  Tags whose values are less
 222 than the special value <code>DT_ENCODING</code> and tags
 223 whose values fall between <code>DT_HIOS</code> and
 224 <code>DT_LOPROC</code> do not follow these rules.
 225 <p>
 226 The following table summarizes the tag requirements
 227 for executable and shared object files.
 228 If a tag is marked ``mandatory'', the dynamic linking
 229 array for an ABI-conforming file must have an entry of that type.
 230 Likewise, ``optional'' means an entry for the tag may appear
 231 but is not required.
 232 <hr>
 233 <b>Figure 5-10: Dynamic Array Tags</b>, <code>d_tag</code>
 234 <p>
 235 <table border cellspacing=0>
 236 <th><b>Name</b></th>
 237 <th><b>Value</b></th>
 238 <th><code>d_un</code></th>
 239 <th><b>Executable</b></th>
 240 <th><b>Shared Object</b></th>
 241 <tr>
 242 <td><code>DT_NULL</code></td>
 243 <td align=right><code>0</code></td>
 244 <td>ignored</td>
 245 <td>mandatory</td>
 246 <td>mandatory</td>
 247 </tr>
 248 <tr>
 249 <td><code>DT_NEEDED</code></td>
 250 <td align=right><code>1</code></td>
 251 <td><code>d_val</code></td>
 252 <td>optional</td>
 253 <td>optional</td>
 254 </tr>
 255 <tr>
 256 <td><code>DT_PLTRELSZ</code></td>
 257 <td align=right><code>2</code></td>
 258 <td><code>d_val</code></td>
 259 <td>optional</td>
 260 <td>optional</td>
 261 </tr>
 262 <tr>
 263 <td><code>DT_PLTGOT</code></td>
 264 <td align=right><code>3</code></td>
 265 <td><code>d_ptr</code></td>
 266 <td>optional</td>
 267 <td>optional</td>
 268 </tr>
 269 <tr>
 270 <td><code>DT_HASH</code></td>
 271 <td align=right><code>4</code></td>
 272 <td><code>d_ptr</code></td>
 273 <td>mandatory</td>
 274 <td>mandatory</td>
 275 </tr>
 276 <tr>
 277 <td><code>DT_STRTAB</code></td>
 278 <td align=right><code>5</code></td>
 279 <td><code>d_ptr</code></td>
 280 <td>mandatory</td>
 281 <td>mandatory</td>
 282 </tr>
 283 <tr>
 284 <td><code>DT_SYMTAB</code></td>
 285 <td align=right><code>6</code></td>
 286 <td><code>d_ptr</code></td>
 287 <td>mandatory</td>
 288 <td>mandatory</td>
 289 </tr>
 290 <tr>
 291 <td><code>DT_RELA</code></td>
 292 <td align=right><code>7</code></td>
 293 <td><code>d_ptr</code></td>
 294 <td>mandatory</td>
 295 <td>optional</td>
 296 </tr>
 297 <tr>
 298 <td><code>DT_RELASZ</code></td>
 299 <td align=right><code>8</code></td>
 300 <td><code>d_val</code></td>
 301 <td>mandatory</td>
 302 <td>optional</td>
 303 </tr>
 304 <tr>
 305 <td><code>DT_RELAENT</code></td>
 306 <td align=right><code>9</code></td>
 307 <td><code>d_val</code></td>
 308 <td>mandatory</td>
 309 <td>optional</td>
 310 </tr>
 311 <tr>
 312 <td><code>DT_STRSZ</code></td>
 313 <td align=right><code>10</code></td>
 314 <td><code>d_val</code></td>
 315 <td>mandatory</td>
 316 <td>mandatory</td>
 317 </tr>
 318 <tr>
 319 <td><code>DT_SYMENT</code></td>
 320 <td align=right><code>11</code></td>
 321 <td><code>d_val</code></td>
 322 <td>mandatory</td>
 323 <td>mandatory</td>
 324 </tr>
 325 <tr>
 326 <td><code>DT_INIT</code></td>
 327 <td align=right><code>12</code></td>
 328 <td><code>d_ptr</code></td>
 329 <td>optional</td>
 330 <td>optional</td>
 331 </tr>
 332 <tr>
 333 <td><code>DT_FINI</code></td>
 334 <td align=right><code>13</code></td>
 335 <td><code>d_ptr</code></td>
 336 <td>optional</td>
 337 <td>optional</td>
 338 </tr>
 339 <tr>
 340 <td><code>DT_SONAME</code></td>
 341 <td align=right><code>14</code></td>
 342 <td><code>d_val</code></td>
 343 <td>ignored</td>
 344 <td>optional</td>
 345 </tr>
 346 <tr>
 347 <td><code>DT_RPATH&#42</code></td>
 348 <td align=right><code>15</code></td>
 349 <td><code>d_val</code></td>
 350 <td>optional</td>
 351 <td>ignored</td>
 352 </tr>
 353 <tr>
 354 <td><code>DT_SYMBOLIC&#42</code></td>
 355 <td align=right><code>16</code></td>
 356 <td>ignored</td>
 357 <td>ignored</td>
 358 <td>optional</td>
 359 </tr>
 360 <tr>
 361 <td><code>DT_REL</code></td>
 362 <td align=right><code>17</code></td>
 363 <td><code>d_ptr</code></td>
 364 <td>mandatory</td>
 365 <td>optional</td>
 366 </tr>
 367 <tr>
 368 <td><code>DT_RELSZ</code></td>
 369 <td align=right><code>18</code></td>
 370 <td><code>d_val</code></td>
 371 <td>mandatory</td>
 372 <td>optional</td>
 373 </tr>
 374 <tr>
 375 <td><code>DT_RELENT</code></td>
 376 <td align=right><code>19</code></td>
 377 <td><code>d_val</code></td>
 378 <td>mandatory</td>
 379 <td>optional</td>
 380 </tr>
 381 <tr>
 382 <td><code>DT_PLTREL</code></td>
 383 <td align=right><code>20</code></td>
 384 <td><code>d_val</code></td>
 385 <td>optional</td>
 386 <td>optional</td>
 387 </tr>
 388 <tr>
 389 <td><code>DT_DEBUG</code></td>
 390 <td align=right><code>21</code></td>
 391 <td><code>d_ptr</code></td>
 392 <td>optional</td>
 393 <td>ignored</td>
 394 </tr>
 395 <tr>
 396 <td><code>DT_TEXTREL&#42</code></td>
 397 <td align=right><code>22</code></td>
 398 <td>ignored</td>
 399 <td>optional</td>
 400 <td>optional</td>
 401 </tr>
 402 <tr>
 403 <td><code>DT_JMPREL</code></td>
 404 <td align=right><code>23</code></td>
 405 <td><code>d_ptr</code></td>
 406 <td>optional</td>
 407 <td>optional</td>
 408 </tr>
 409 <tr>
 410 <td><code>DT_BIND_NOW&#42</code></td>
 411 <td align=right><code>24</code></td>
 412 <td>ignored</td>
 413 <td>optional</td>
 414 <td>optional</td>
 415 </tr>
 416 <tr>
 417 <td><code>DT_INIT_ARRAY</code></td>
 418 <td align=right><code>25</code></td>
 419 <td><code>d_ptr</code></td>
 420 <td>optional</td>
 421 <td>optional</td>
 422 </tr>
 423 <tr>
 424 <td><code>DT_FINI_ARRAY</code></td>
 425 <td align=right><code>26</code></td>
 426 <td><code>d_ptr</code></td>
 427 <td>optional</td>
 428 <td>optional</td>
 429 </tr>
 430 <tr>
 431 <td><code>DT_INIT_ARRAYSZ</code></td>
 432 <td align=right><code>27</code></td>
 433 <td><code>d_val</code></td>
 434 <td>optional</td>
 435 <td>optional</td>
 436 </tr>
 437 <tr>
 438 <td><code>DT_FINI_ARRAYSZ</code></td>
 439 <td align=right><code>28</code></td>
 440 <td><code>d_val</code></td>
 441 <td>optional</td>
 442 <td>optional</td>
 443 </tr>
 444 <td><code>DT_RUNPATH</code></td>
 445 <td align=right><code>29</code></td>
 446 <td><code>d_val</code></td>
 447 <td>optional</td>
 448 <td>optional</td>
 449 </tr>
 450 <td><code>DT_FLAGS</code></td>
 451 <td align=right><code>30</code></td>
 452 <td><code>d_val</code></td>
 453 <td>optional</td>
 454 <td>optional</td>
 455 </tr>
 456 <tr>
 457 <td><code>DT_ENCODING</code></td>
 458 <td align=right><code>32</code></td>
 459 <td>unspecified</td>
 460 <td>unspecified</td>
 461 <td>unspecified</td>
 462 </tr>
 463 <tr>
 464 <td><code>DT_PREINIT_ARRAY</code></td>
 465 <td align=right><code>32</code></td>
 466 <td><code>d_ptr</code></td>
 467 <td>optional</td>
 468 <td>ignored</td>
 469 </tr>
 470 <tr>
 471 <td><code>DT_PREINIT_ARRAYSZ</code></td>
 472 <td align=right><code>33</code></td>
 473 <td><code>d_val</code></td>
 474 <td>optional</td>
 475 <td>ignored</td>
 476 </tr>
 477 <tr>
 478 <td><code>DT_LOOS</code></td>
 479 <td align=right><code>0x6000000D</code></td>
 480 <td>unspecified</td>
 481 <td>unspecified</td>
 482 <td>unspecified</td>
 483 </tr>
 484 <tr>
 485 <td><code>DT_HIOS</code></td>
 486 <td align=right><code>0x6ffff000</code></td>
 487 <td>unspecified</td>
 488 <td>unspecified</td>
 489 <td>unspecified</td>
 490 </tr>
 491 <tr>
 492 <td><code>DT_LOPROC</code></td>
 493 <td align=right><code>0x70000000</code></td>
 494 <td>unspecified</td>
 495 <td>unspecified</td>
 496 <td>unspecified</td>
 497 </tr>
 498 <tr>
 499 <td><code>DT_HIPROC</code></td>
 500 <td align=right><code>0x7fffffff</code></td>
 501 <td>unspecified</td>
 502 <td>unspecified</td>
 503 <td>unspecified</td>
 504 </tr>
 505 </table>
 506 <p>
 507 &#42 Signifies an entry that is at level 2.
 508 <hr>
 509 <DL COMPACT>
 510 <p><dt><code>DT_NULL</code><dd>
 511 An entry with a <code>DT_NULL</code> tag marks the end of the
 512 <code>_DYNAMIC</code> array.
 513 <p><dt><code>DT_NEEDED</code><dd>
 514 This element holds the string table offset of a null-terminated string,
 515 giving the name of a needed library.
 516 The offset is an index into the table recorded in the <code>DT_STRTAB</code> code.
 517 See
 518 <a href=#shobj_dependencies>``Shared Object Dependencies''</a>
 519 for more
 520 information about these names.
 521 The dynamic array may contain multiple entries with
 522 this type.
 523 These entries' relative order is significant, though their
 524 relation to entries of other types is not.
 525 <p><dt><code>DT_PLTRELSZ</code><dd>
 526 This element holds the total size, in bytes,
 527 of the relocation entries associated with the procedure linkage table.
 528 If an entry of type <code>DT_JMPREL</code> is present, a
 529 <code>DT_PLTRELSZ</code> must accompany it.
 530 <p><dt><code>DT_PLTGOT</code><dd>
 531 This element holds an address associated with the procedure linkage table
 532 and/or the global offset table.
 533 See this section in the processor supplement for details.
 534 <p><dt><code>DT_HASH</code><dd>
 535 This element holds the address of the symbol hash table,
 536 described in
 537 <a href=#hash>``Hash Table''</a>.
 538 This hash table refers to the symbol table referenced by the <code>DT_SYMTAB</code>
 539 element.
 540 <p><dt><code>DT_STRTAB</code><dd>
 541 This element holds the address of the string table,
 542 described in Chapter 4.
 543 Symbol names, library names, and other strings reside
 544 in this table.
 545 <p><dt><code>DT_SYMTAB</code><dd>
 546 This element holds the address of the symbol table,
 547 described in the first part of this chapter, with <code>Elf32_Sym</code>
 548 entries for the 32-bit class of files and <code>Elf64_Sym</code>
 549 entries for the 64-bit class of files.
 550 <p><dt><code>DT_RELA</code><dd>
 551 This element holds the address of a relocation table,
 552 described in Chapter 4.
 553 Entries in the table have explicit addends, such as
 554 <code>Elf32_Rela</code> for the 32-bit file class
 555 or <code>Elf64_Rela</code> for the 64-bit file class.
 556 An object file may have multiple relocation sections.
 557 When building the relocation table for an
 558 executable or shared object file, the link editor
 559 catenates those sections to form a single table.
 560 Although the sections remain independent in the object file,
 561 the dynamic linker sees a single table.
 562 When the dynamic linker creates the process image for
 563 an executable file or adds a shared object to the
 564 process image, it reads the relocation table and performs
 565 the associated actions.
 566 If this element is present, the dynamic structure must also have
 567 <code>DT_RELASZ</code> and <code>DT_RELAENT</code> elements.
 568 When relocation is ``mandatory'' for a file, either
 569 <code>DT_RELA</code> or <code>DT_REL</code> may occur (both are permitted but not required).
 570 <p><dt><code>DT_RELASZ</code><dd>
 571 This element holds the total size, in bytes, of the
 572 <code>DT_RELA</code> relocation table.
 573 <p><dt><code>DT_RELAENT</code><dd>
 574 This element holds the size, in bytes, of the
 575 <code>DT_RELA</code> relocation entry.
 576 <p><dt><code>DT_STRSZ</code><dd>
 577 This element holds the size, in bytes, of the string table.
 578 <p><dt><code>DT_SYMENT</code><dd>
 579 This element holds the size, in bytes, of a symbol table entry.
 580 <p><dt><code>DT_INIT</code><dd>
 581 This element holds the address of the initialization function,
 582 discussed in
 583 <a href=#init_fini>``Initialization and Termination Functions''</a>
 584 below.
 585 <p><dt><code>DT_FINI</code><dd>
 586 This element holds the address of the termination function,
 587 discussed in
 588 <a href=#init_fini>``Initialization and Termination Functions''</a>
 589 below.
 590 <p><dt><code>DT_SONAME</code><dd>
 591 This element holds the string table offset of a null-terminated string,
 592 giving the name of the shared object.
 593 The offset is an index into the table recorded in the <code>DT_STRTAB</code> entry.
 594 See
 595 <a href=#shobj_dependencies>``Shared Object Dependencies''</a>
 596 below for more
 597 information about these names.
 598 <a name=dt_rpath></a>
 599 <p><dt><code>DT_RPATH</code><dd>
 600 This element holds the string table offset of a null-terminated search
 601 library search path string discussed in
 602 <a href=#shobj_dependencies>``Shared Object Dependencies''</a>.
 603 The offset is an index into the table recorded in the
 604 <code>DT_STRTAB</code> entry.  This entry is at level 2.  Its
 605 use has been superseded by <a href=#dt_runpath><code>DT_RUNPATH</code></a>.
 606 <p><dt><code>DT_SYMBOLIC</code><dd>
 607 This element's presence in a shared object library alters
 608 the dynamic linker's symbol resolution algorithm for
 609 references within the library.
 610 Instead of starting a symbol search with the
 611 executable file, the dynamic linker starts from the
 612 shared object itself.
 613 If the shared object fails to supply the referenced
 614 symbol, the dynamic linker then searches the
 615 executable file and other shared objects as usual.
 616 This entry is at level 2.  Its use has been superseded
 617 by the <a href=#df_symbolic><code>DF_SYMBOLIC</code></a> flag.
 618 <p><dt><code>DT_REL</code><dd>
 619 This element is similar to <code>DT_RELA</code>,
 620 except its table has implicit addends, such as
 621 <code>Elf32_Rel</code> for the 32-bit file class
 622 or <code>Elf64_Rel</code> for the 64-bit file class.
 623 If this element is present, the dynamic structure must also have
 624 <code>DT_RELSZ</code> and <code>DT_RELENT</code> elements.
 625 <p><dt><code>DT_RELSZ</code><dd>
 626 This element holds the total size, in bytes, of the
 627 <code>DT_REL</code> relocation table.
 628 <p><dt><code>DT_RELENT</code><dd>
 629 This element holds the size, in bytes, of the
 630 <code>DT_REL</code> relocation entry.
 631 <p><dt><code>DT_PLTREL</code><dd>
 632 This member specifies the type of relocation entry
 633 to which the procedure linkage table refers.
 634 The <code>d_val</code> member holds <code>DT_REL</code> or <code>DT_RELA</code>,
 635 as appropriate.
 636 All relocations in a procedure linkage table must use
 637 the same relocation.
 638 <p><dt><code>DT_DEBUG</code><dd>
 639 This member is used for debugging.  Its contents are not specified
 640 for the ABI; programs that access this entry are not
 641 ABI-conforming.
 642 <p><dt><code>DT_TEXTREL</code><dd>
 643 This member's absence signifies that no
 644 relocation entry should cause a modification to a non-writable
 645 segment, as specified by the segment permissions in the program
 646 header table.
 647 If this member is present, one or more relocation entries might
 648 request modifications to a non-writable segment, and the dynamic
 649 linker can prepare accordingly.
 650 This entry is at level 2.  Its use has been superseded
 651 by the <a href=#df_textrel><code>DF_TEXTREL</code></a> flag.
 652 <p><dt><code>DT_JMPREL</code><dd>
 653 If present, this entry's <code>d_ptr</code>
 654 member holds the address of relocation entries associated solely
 655 with the procedure linkage table.
 656 Separating these relocation entries lets the dynamic linker ignore
 657 them during process initialization, if lazy binding is enabled.
 658 If this entry is present, the related entries of types
 659 <code>DT_PLTRELSZ</code> and <code>DT_PLTREL</code>
 660 must also be present.
 661 <p><dt><code>DT_BIND_NOW</code><dd>
 662 If present in a shared object or executable, this entry
 663 instructs the dynamic linker to process all relocations
 664 for the object containing this entry before transferring
 665 control to the program.
 666 The presence of this entry takes
 667 precedence over a directive to use lazy binding for this object when
 668 specified through the environment or via <code>dlopen</code>(BA_LIB).
 669 This entry is at level 2.  Its use has been superseded
 670 by the <a href=#df_bind_now><code>DF_BIND_NOW</code></a> flag.
 671 <p><dt><code>DT_INIT_ARRAY</code><dd>
 672 <a name=dt_init_array></a>
 673 This element holds the address of the array of pointers to initialization
 674 functions,
 675 discussed in
 676 <a href=#init_fini>``Initialization and Termination Functions''</a>
 677 below.
 678 <p><dt><code>DT_FINI_ARRAY</code><dd>
 679 This element holds the address of the array of pointers to termination
 680 functions,
 681 discussed in
 682 <a href=#init_fini>``Initialization and Termination Functions''</a>
 683 below.
 684 <p><dt><code>DT_INIT_ARRAYSZ</code><dd>
 685 This element holds the size in bytes of the array of initialization
 686 functions pointed to by the <code>DT_INIT_ARRAY</code> entry.
 687 If an object has a <code>DT_INIT_ARRAY</code> entry, it must
 688 also have a <code>DT_INIT_ARRAYSZ</code> entry.
 689 <p><dt><code>DT_FINI_ARRAYSZ</code><dd>
 690 This element holds the size in bytes of the array of termination
 691 functions pointed to by the <code>DT_FINI_ARRAY</code> entry.
 692 If an object has a <code>DT_FINI_ARRAY</code> entry, it must
 693 also have a <code>DT_FINI_ARRAYSZ</code> entry.
 694 <a name=dt_runpath></a>
 695 <p><dt><code>DT_RUNPATH</code><dd>
 696 This element holds the string table offset of a null-terminated
 697 library search path string discussed in
 698 <a href=#shobj_dependencies>``Shared Object Dependencies''</a>.
 699 The offset is an index into the table recorded in the
 700 <code>DT_STRTAB</code> entry.
 701 <p><dt><code>DT_FLAGS</code><dd>
 702 This element holds flag values specific to the object being
 703 loaded.  Each flag value will have the name <code>DF_</code><i>flag_name</i>.
 704 Defined values and their meanings are described <a href=#df_flags>below</a>.
 705 All other values are reserved.
 706 <p><dt><code>DT_PREINIT_ARRAY</code><dd>
 707 This element holds the address of the array of pointers to pre-initialization
 708 functions,
 709 discussed in
 710 <a href=#init_fini>``Initialization and Termination Functions''</a>
 711 below.  The <code>DT_PREINIT_ARRAY</code> table is processed only
 712 in an executable file; it is ignored if contained in a shared object.
 713 <p><dt><code>DT_PREINIT_ARRAYSZ</code><dd>
 714 This element holds the size in bytes of the array of pre-initialization
 715 functions pointed to by the <code>DT_PREINIT_ARRAY</code> entry.
 716 If an object has a <code>DT_PREINIT_ARRAY</code> entry, it must
 717 also have a <code>DT_PREINIT_ARRAYSZ</code> entry.  As with
 718 <code>DT_PREINIT_ARRAY</code>, this entry is ignored if it appears
 719 in a shared object.
 720 <p><dt><code>DT_ENCODING</code><dd>
 721 Values greater than or equal to <code>DT_ENCODING</code>
 722 and less than <code>DT_LOOS</code>
 723 follow the rules for the interpretation of the <code>d_un</code> union
 724 described <a href=#tag_encodings>above</a>.
 725 <p><dt><code>DT_LOOS</code> through <code>DT_HIOS</code><dd>
 726 Values in this inclusive range
 727 are reserved for operating system-specific semantics.
 728 All such values follow the rules for the interpretation of the
 729 <code>d_un</code> union described <a href=#tag_encodings>above</a>.
 730 <p><dt><code>DT_LOPROC</code> through <code>DT_HIPROC</code><dd>
 731 Values in this inclusive range
 732 are reserved for processor-specific semantics. If meanings
 733 are specified, the processor supplement explains them.
 734 All such values follow the rules for the interpretation of the
 735 <code>d_un</code> union described <a href=#tag_encodings>above</a>.
 736 </dl>
 737 <p>
 738 Except for the <code>DT_NULL</code> element at the end of the array,
 739 and the relative order of <code>DT_NEEDED</code>
 740 elements, entries may appear in any order.
 741 Tag values not appearing in the table are reserved.
 742 <a name=df_flags></a>
 743 <hr>
 744 <b>Figure 5-11: <code>DT_FLAGS</code> values</b>
 745 <p>
 746 <table border cellspacing=0>
 747 <th><b>Name</b></th>
 748 <th><b>Value</b></th>
 749 <tr>
 750 <td><code>DF_ORIGIN</code></td>
 751 <td align=right><code>0x1</code></td>
 752 </tr>
 753 <tr>
 754 <td><code>DF_SYMBOLIC</code></td>
 755 <td align=right><code>0x2</code></td>
 756 </tr>
 757 <tr>
 758 <td><code>DF_TEXTREL</code></td>
 759 <td align=right><code>0x4</code></td>
 760 </tr>
 761 <tr>
 762 <td><code>DF_BIND_NOW</code></td>
 763 <td align=right><code>0x8</code></td>
 764 </tr>
 765 <tr>
 766 <td><code>DF_STATIC_TLS</code></td>
 767 <td align=right><code>0x10</code></td>
 768 </tr>
 769 </table>
 770 <hr>
 771 <dl compact>
 772 <p><dt><code>DF_ORIGIN</code><dd>
 773 This flag signifies that the object being loaded may make reference
 774 to the <code>$ORIGIN</code> substitution string (see <a href=#substitution>``Substitution Sequences''</a>).
 775 The dynamic linker must determine the pathname of the object
 776 containing this entry when the object is loaded.
 777 <a name=df_symbolic></a>
 778 <p><dt><code>DF_SYMBOLIC</code><dd>
 779 If this flag is set in a shared object library,
 780 the dynamic linker's symbol resolution algorithm for
 781 references within the library is changed.
 782 Instead of starting a symbol search with the
 783 executable file, the dynamic linker starts from the
 784 shared object itself.
 785 If the shared object fails to supply the referenced
 786 symbol, the dynamic linker then searches the
 787 executable file and other shared objects as usual.
 788 <a name=df_textrel></a>
 789 <p><dt><code>DF_TEXTREL</code><dd>
 790 If this flag is not set, no
 791 relocation entry should cause a modification to a non-writable
 792 segment, as specified by the segment permissions in the program
 793 header table.
 794 If this flag is set, one or more relocation entries might
 795 request modifications to a non-writable segment, and the dynamic
 796 linker can prepare accordingly.
 797 <a name=df_bind_now></a>
 798 <p><dt><code>DF_BIND_NOW</code><dd>
 799 If set in a shared object or executable, this flag
 800 instructs the dynamic linker to process all relocations
 801 for the object containing this entry before transferring
 802 control to the program.
 803 The presence of this entry takes
 804 precedence over a directive to use lazy binding for this object when
 805 specified through the environment or via <code>dlopen</code>(BA_LIB).
 806 <a name=df_static_tls></a>
 807 <p><dt><code>DF_STATIC_TLS</code><dd>
 808 If set in a shared object or executable,
 809 this flag instructs the dynamic linker to reject
 810 attempts to load this file dynamically.
 811 It indicates that the shared object or executable
 812 contains code using a <i>static thread-local storage</i> scheme.
 813 Implementations need not support any form of thread-local storage.
 814 </dl>
 815 <a name=shobj_dependencies></a>
 816 <h2>Shared Object Dependencies</h2>
 817 When the link editor processes an archive library,
 818 it extracts library members and copies them into
 819 the output object file.
 820 These statically linked services are available during
 821 execution without involving the dynamic linker.
 822 Shared objects also provide services, and
 823 the dynamic linker must attach the proper shared object files to
 824 the process image for execution.
 825 <p>
 826 When the dynamic linker creates the memory segments for
 827 an object file, the dependencies (recorded in
 828 <code>DT_NEEDED</code> entries of the dynamic structure)
 829 tell what shared objects are needed to
 830 supply the program's services.
 831 By repeatedly connecting referenced shared objects and
 832 their dependencies, the dynamic linker builds a complete process image.
 833 When resolving symbolic references, the dynamic linker
 834 examines the symbol tables with a breadth-first search.
 835 That is, it first looks at the symbol table of the
 836 executable program itself, then at the symbol tables
 837 of the <code>DT_NEEDED</code> entries (in order),
 838 and then at the second level <code>DT_NEEDED</code> entries, and
 839 so on.  Shared object files must be readable by the process;
 840 other permissions are not required.
 841 <hr>
 842 <img src=warning.gif alt="NOTE:">
 843 Even when a shared object is referenced multiple
 844 times in the dependency list, the dynamic linker will
 845 connect the object only once to the process.
 846 <hr><p>
 847 <p>
 848 Names in the dependency list are copies either of the
 849 <code>DT_SONAME</code> strings or the path names of the shared objects used to build
 850 the object file.
 851 For example, if the link editor builds an executable
 852 file using one shared object with a
 853 <code>DT_SONAME</code> entry of <code>lib1</code>
 854 and another shared object library with the path name
 855 <code>/usr/lib/lib2</code>, the executable file will contain
 856 <code>lib1</code> and <code>/usr/lib/lib2</code> in its dependency list.
 857 <p>
 858 If a shared object name has one or more slash (<code>/</code>)
 859 characters anywhere in the name, such as <code>/usr/lib/lib2</code>
 860 or <code>directory/file</code>, the dynamic linker uses that string directly
 861 as the path name.
 862 If the name has no slashes, such as <code>lib1</code>,
 863 three facilities specify shared object path searching.
 864 <ul>
 865 <hr><p>
 866 <ul>
 867 <p><li>
 868 The dynamic array tag <code>DT_RUNPATH</code> gives a string that
 869 holds a list of directories, separated by colons (<code>:</code>).
 870 For example, the string
 871 <code>/home/dir/lib:/home/dir2/lib:</code>
 872 tells the dynamic linker to search first the directory
 873 <code>/home/dir/lib</code>, then <code>/home/dir2/lib</code>,
 874 and then the current directory to find dependencies.
 875 <p>
 876 The set of directories specified by a given <code>DT_RUNPATH</code>
 877 entry is used to find only the immediate dependencies
 878 of the executable or shared object containing the <code>DT_RUNPATH</code>
 879 entry.  That is, it is used only for those dependencies contained in
 880 the <code>DT_NEEDED</code> entries of the dynamic structure containing
 881 the <code>DT_RUNPATH</code> entry, itself.
 882 One object's <code>DT_RUNPATH</code> entry does not affect the search
 883 for any other object's dependencies.
 884 <p><li>
 885 A variable called <code>LD_LIBRARY_PATH</code>
 886 in the process environment [see <code>exec</code>(BA_OS)]
 887 may hold a list of directories as above, optionally
 888 followed by a semicolon (<code>;</code>) and
 889 another directory list.
 890 The following values would be equivalent to the previous example:
 891 <ul>
 892 <p><li>
 893 <code>LD_LIBRARY_PATH=/home/dir/usr/lib:/home/dir2/usr/lib:</code>
 894 <p><li>
 895 <code>LD_LIBRARY_PATH=/home/dir/usr/lib;/home/dir2/usr/lib:</code>
 896 <p><li>
 897 <code>LD_LIBRARY_PATH=/home/dir/usr/lib:/home/dir2/usr/lib:;</code>
 898 </ul>
 899 <p>
 900 Although some programs (such as the link editor) treat the lists
 901 before and after the semicolon differently,
 902 the dynamic linker does not.
 903 Nevertheless, the dynamic linker accepts the semicolon
 904 notation, with the semantics described previously.
 905 <p>
 906 All <code>LD_LIBRARY_PATH</code> directories are searched before those from
 907 <code>DT_RUNPATH</code>.
 908 <p><li>
 909 Finally, if the other two groups of directories
 910 fail to locate the desired library, the dynamic linker searches
 911 the default directories, <code>/usr/lib</code> or such other
 912 directories as may be specified by the ABI supplement for a
 913 given processor.
 914 </ul>
 915 <hr>
 916 <p>
 917 When the dynamic linker is searching for shared objects, it is
 918 not a fatal error if an ELF file with the wrong attributes
 919 is encountered in the search.  Instead, the dynamic linker
 920 shall exhaust the search of all paths before determining
 921 that a matching object could not be found.  For this determination,
 922 the relevant attributes are contained in the following ELF header fields:
 923 <code>e_ident[EI_DATA]</code>,
 924 <code>e_ident[EI_CLASS]</code>,
 925 <code>e_ident[EI_OSABI]</code>,
 926 <code>e_ident[EI_ABIVERSION]</code>,
 927 <code>e_machine</code>,
 928 <code>e_type</code>, <code>e_flags</code>
 929 and <code>e_version</code>.
 930 <hr>
 931 <img src=warning.gif alt="NOTE:">
 932 For security, the dynamic linker ignores
 933 <code>LD_LIBRARY_PATH</code> for set-user and
 934 set-group ID programs.
 935 It does, however, search <code>DT_RUNPATH</code> directories
 936 and the default directories.
 937 The same restriction may be applied to processes that have more than
 938 minimal privileges on systems with installed extended security
 939 mechanisms.
 940 <hr>
 941 <img src="warning.gif" alt="NOTE:">
 942 A fourth search facility, the dynamic array tag <code>DT_RPATH</code>,
 943 has been moved to level 2 in the ABI.
 944 It provides a colon-separated list of directories to search.
 945 Directories specified by <code>DT_RPATH</code> are searched
 946 before directories specified by <code>LD_LIBRARY_PATH</code>.
 947 <p>
 948 If both <code>DT_RPATH</code> and <code>DT_RUNPATH</code>
 949 entries appear in a single object's dynamic array,
 950 the dynamic linker processes only the <code>DT_RUNPATH</code>
 951 entry.
 952 <hr>
 953 <a name=substitution></a>
 954 <h3>Substitution Sequences</h3>
 955 Within a string provided by dynamic array entries with the
 956 <code>DT_NEEDED</code> or <code>DT_RUNPATH</code> tags and in
 957 pathnames passed as parameters to the <code>dlopen()</code> routine, a
 958 dollar sign (<code>$</code>) introduces a substitution sequence.
 959 This sequence consists of the dollar sign immediately followed
 960 by either the longest <i>name</i> sequence or a name contained
 961 within left and right braces (<code>{</code>) and (<code>}</code>).
 962 A name is a sequence of bytes that start with either a letter or
 963 an underscore followed by zero or more letters, digits or underscores.
 964 If a dollar sign is not immediately followed by a name or a
 965 brace-enclosed name, the behavior of the dynamic linker is unspecified.
 966 <p>
 967 If the name is ``<code>ORIGIN</code>'', then the substitution
 968 sequence is replaced by the dynamic linker with the absolute
 969 pathname of the directory in which the object containing the
 970 substitution sequence originated.  Moreover, the pathname will
 971 contain no symbolic links or use of ``<code>.</code>'' or
 972 ``<code>..</code>'' components.
 973 Otherwise (when the name is not ``<code>ORIGIN</code>'')
 974 the behavior of the dynamic linker is unspecified.
 975 <p>
 976 When the dynamic linker loads an object that uses <code>$ORIGIN</code>,
 977 it must calculate the pathname of the directory containing the object.
 978 Because this calculation can be computationally expensive,
 979 implementations may want to avoid the calculation for objects
 980 that do not use <code>$ORIGIN</code>.
 981 If an object calls <code>dlopen()</code> with a string
 982 containing <code>$ORIGIN</code> and does not use <code>$ORIGIN</code>
 983 in one if its dynamic array entries,
 984 the dynamic linker may not have calculated the
 985 pathname for the object until the <code>dlopen()</code> actually
 986 occurs.  Since the application may have changed its current
 987 working directory before the <code>dlopen()</code> call,
 988 the calculation may not yield the correct result.
 989 To avoid this possibility, an object may signal its intention
 990 to reference <code>$ORIGIN</code> by setting the
 991 <a href=#df_flags><code>DF_ORIGIN</code> flag</a>.
 992 An implementation may reject an attempt to use <code>$ORIGIN</code>
 993 within a <code>dlopen()</code> call from an object that
 994 did not set the <code>DF_ORIGIN</code> flag and did not
 995 use <code>$ORIGIN</code> within its dynamic array.
 996 <hr>
 997 <img src=warning.gif alt="NOTE:">
 998 For security, the dynamic linker does not allow use of
 999 <code>$ORIGIN</code> substitution sequences for set-user and
1000 set-group ID programs.  For such sequences that appear
1001 within strings specified by <code>DT_RUNPATH</code> dynamic
1002 array entries, the specific search path containing the
1003 <code>$ORIGIN</code> sequence is ignored (though other
1004 search paths in the same string are processed).
1005 <code>$ORIGIN</code> sequences within a <code>DT_NEEDED</code>
1006 entry or path passed as a parameter to <code>dlopen()</code>
1007 are treated as errors.
1008 The same restrictions may be applied to processes that have more than
1009 minimal privileges on systems with installed extended security
1010 mechanisms.
1011 <hr>
1012 <a name=got></a>
1013 <h2>Global Offset Table</h2>
1014 <hr>
1015 <img src=warning.gif alt="NOTE:">
1016 This section requires processor-specific information.
1017 The <i>System V Application Binary Interface</i> supplement
1018 for the desired processor describes the details.
1019 <hr><p>
1020 <a name=plt></a>
1021 <h2>Procedure Linkage Table</h2>
1022 <hr>
1023 <img src=warning.gif alt="NOTE:">
1024 This section requires processor-specific information.
1025 The <i>System V Application Binary Interface</i> supplement
1026 for the desired processor describes the details.
1027 <hr><p>
1028 <a name=hash></a>
1029 <h2>Hash Table</h2>
1030 A hash table of <code>Elf32_Word</code>
1031 objects supports symbol table access.  The same table
1032 layout is used for both the 32-bit and 64-bit file class.
1033 Labels appear below
1034 to help explain the hash table organization,
1035 but they are not part of the specification.
1036 <hr>
1037 <b>Figure 5-12: Symbol Hash Table</b>
1038 <p>
1039 <table border cellspacing=0>
1040 <tr><td align=center><code>nbucket</code></td></tr>
1041 <tr><td align=center><code>nchain</code></td></tr>
1042 <tr><td align=center><code>bucket[0]<br>. . .<br>bucket[nbucket-1]</code></td></tr>
1043 <tr><td align=center><code>chain[0]<br>. . .<br>chain[nchain-1]</code></td></tr>
1044 </table>
1045 <hr>
1046 <p>
1047 The <code>bucket</code> array contains <code>nbucket</code>
1048 entries, and the <code>chain</code> array contains <code>nchain</code>
1049 entries; indexes start at 0.
1050 Both <code>bucket</code> and <code>chain</code>
1051 hold symbol table indexes.
1052 Chain table entries parallel the symbol table.
1053 The number of symbol table entries should equal
1054 <code>nchain</code>;
1055 so symbol table indexes also select chain table entries.
1056 A hashing function (shown below) accepts a symbol name and returns a
1057 value that may be used to compute a <code>bucket</code> index.
1058 Consequently, if the hashing function returns the value
1059 <i>x</i> for some name, <code>bucket[</code><i>x</i><code>%nbucket]</code> gives
1060 an index, <i>y</i>,
1061 into both the symbol table and the chain table.
1062 If the symbol table entry is not the one desired,
1063 <code>chain[</code><i>y</i><code>]</code> gives the next symbol table entry
1064 with the same hash value.
1065 One can follow the <code>chain</code>
1066 links until either the selected symbol table entry
1067 holds the desired name or the <code>chain</code> entry contains the value
1068 <code>STN_UNDEF</code>.
1069 <hr>
1070 <b>Figure 5-13: Hashing Function</b>
1071 <p>
1072 <pre>
1073 <code>
1074 unsigned long
1075 elf_hash(const unsigned char *name)
1076 {
1077         unsigned long   h = 0, g;
1078         while (*name)
1079         {
1080                 h = (h &lt;&lt; 4) + *name++;
1081                 if (g = h &amp; 0xf0000000)
1082                         h ^= g &gt;&gt; 24;
1083                 h &amp;= ~g;
1084         }
1085         return h;
1086 }
1087 </code>
1088 </pre>
1089 <hr>
1090 <a name=init_fini></a>
1091 <h2>Initialization and Termination Functions</h2>
1092 After the dynamic linker has built the process image
1093 and performed the relocations, each shared object and the executable
1094 file get the opportunity to execute some initialization functions.
1095 All shared object initializations happen before the executable
1096 file gains control.
1097 <p>
1098 Before the initialization functions for any object A is called, the initialization
1099 functions for any other objects that object A depends on are called.
1100 For these purposes, an object A depends on another object B,
1101 if B appears in A's list of needed objects (recorded in the <code>DT_NEEDED</code>
1102 entries of the dynamic structure).
1103 The order of initialization for circular dependencies is undefined.
1104 <p>
1105 The initialization of objects occurs by recursing through the needed
1106 entries of each object.
1107 The initialization functions for an object are invoked after the needed
1108 entries for that object have been processed.
1109 The order of processing among the entries of a particular list of
1110 needed objects is unspecified.
1111 <hr>
1112 <img src=warning.gif alt="NOTE:">
1113 Each processor supplement may optionally further restrict
1114 the algorithm used to determine the order of initialization.
1115 Any such restriction, however, may not conflict with
1116 the rules described by this specification.
1117 <hr>
1118 <p>
1119 The following example illustrates two of the possible correct orderings
1120 which can be generated for the example NEEDED lists.
1121 In this example the <i>a.out</i> is dependent on <code>b</code>, <code>d</code>, and <code>e</code>.
1122 <code>b</code> is dependent on <code>d</code> and <code>f</code>, while <code>d</code> is dependent on <code>e</code> and <code>g</code>.
1123 From this information a dependency graph can be drawn.
1124 The above algorithm on initialization will then allow the following
1125 specified initialization orderings among others.
1126 <hr>
1127 <b>Figure 5-14: Initialization Ordering Example</b>
1128 <p>
1129 <p><IMG SRC=init_example.gif><p>
1130 <hr>
1131 <p>
1132 <a name=fini_order></a>
1133 Similarly, shared objects and executable files may have termination
1134 functions, which are executed with the
1135 <code>atexit</code>(BA_OS) mechanism after the base process begins its
1136 termination sequence.
1137 The termination functions for any object A must be called before
1138 the termination functions for any other objects that object A depends
1139 on.  For these purposes, an object A depends on another object B,
1140 if B appears in A's list of needed objects (recorded in the <code>DT_NEEDED</code>
1141 entries of the dynamic structure).
1142 The order of termination for circular dependencies is undefined.
1143 <p>
1144 <a name=preinit></a>
1145 Finally, an executable file may have pre-initialization functions.
1146 These functions are executed after the dynamic linker has built
1147 the process image and performed relocations but before any shared
1148 object initialization functions.  Pre-initialization functions are
1149 not permitted in shared objects.
1150 <hr>
1151 <img src=warning.gif alt="NOTE:">
1152 Complete initialization of system libraries may not have occurred when
1153 pre-initializations are executed, so some features of the system
1154 may not be available to pre-initialization code.  In general,
1155 use of pre-initialization code can be considered portable only
1156 if it has no dependencies on system libraries.
1157 <hr><p>
1158 <p>
1159 The dynamic linker ensures that it will not execute any initialization,
1160 pre-initialization, or termination functions more than once.
1161 <p>
1162 Shared objects designate their
1163 initialization and termination code in one of two ways.
1164 First, they may specify the address of a function to execute
1165 via the
1166 <code>DT_INIT</code>
1167 and
1168 <code>DT_FINI</code>
1169 entries in the dynamic structure, described in
1170 <a href=#dynamic_section>``Dynamic Section''</a>
1171 above.
1172 <hr>
1173 <img src=warning.gif alt="NOTE:">
1174 Note that the address of a function
1175 need not be the same as a pointer to a function
1176 as defined by the processor supplement.
1177 <hr>
1178 <p>
1179 Shared objects may also (or instead) specify the address and size of
1180 an array of function pointers.  Each element of this
1181 array is a pointer to a function to be executed by the dynamic linker.
1182 Each array element is the size of a pointer in the
1183 programming model followed by the object containing
1184 the array.  The address of the array of initialization
1185 function pointers is specified by the <code>DT_INIT_ARRAY</code>
1186 entry in the dynamic structure.  Similarly, the address of
1187 the array of pre-initialization functions is specified by
1188 <code>DT_PREINIT_ARRAY</code> and the address of the array
1189 of termination functions is specified by <code>DT_FINI_ARRAY</code>.
1190 The size of each array is specified by the <code>DT_INIT_ARRAYSZ</code>,
1191 <code>DT_PREINIT_ARRAYSZ</code>, and <code>DT_FINI_ARRAYSZ</code>
1192 entries.
1193 <a name=pointer_note></a>
1194 <hr>
1195 <img src=warning.gif alt="NOTE:">
1196 The addresses contained in the initialization and termination arrays
1197 are function pointers as defined by the processor supplement for
1198 each processor.  On some architectures, a function pointer may not
1199 contain the actual address of the function.
1200 <hr><p>
1201 <a name=init_order></a>
1202 <p>
1203 The functions pointed to in the arrays
1204 specified by <code>DT_INIT_ARRAY</code> and by <code>DT_PREINIT_ARRAY</code>
1205 are executed by the dynamic
1206 linker in the same order in which their addresses appear in
1207 the array; those specified by <code>DT_FINI_ARRAY</code>
1208 are executed in reverse order.
1209 <p>
1210 If an object contains both <code>DT_INIT</code>
1211 and <code>DT_INIT_ARRAY</code> entries, the function referenced
1212 by the <code>DT_INIT</code> entry is processed before those
1213 referenced by the <code>DT_INIT_ARRAY</code> entry for that object.
1214 If an object contains both <code>DT_FINI</code>
1215 and <code>DT_FINI_ARRAY</code> entries, the functions referenced
1216 by the <code>DT_FINI_ARRAY</code> entry are processed before the one
1217 referenced by the <code>DT_FINI</code> entry for that object.
1218 <hr>
1219 <img src=warning.gif alt="NOTE:">
1220 Although the
1221 <code>atexit</code>(BA_OS)
1222 termination processing normally will be done,
1223 it is not guaranteed to have executed upon process death.
1224 In particular, the process will not execute the termination processing
1225 if it calls <code>_exit</code> [see
1226 <code>exit</code>(BA_OS)]
1227 or if the process dies because it received a signal
1228 that it neither caught nor ignored.
1229 <hr><p>
1230 <p>
1231 <a name=register_init></a>
1232 The processor supplement for each processor specifies whether the
1233 dynamic linker is responsible for calling the executable file's
1234 initialization function or registering the executable file's
1235 termination function with
1236 <code>atexit</code>(BA_OS).
1237 Termination functions specified by users via the
1238 <code>atexit</code>(BA_OS)
1239 mechanism
1240 must be executed before any termination functions of shared objects.
1241 <hr>
1242 <a href=ch5.prog_loading.html><img src=previous.gif alt="Previous">
1243 <a href=contents.html><img src=contents.gif alt="Contents"></a>
1244 <hr>
1245 <i>
1246 <small>
1247 &#169; 1997, 1998, 1999, 2000, 2001 The Santa Cruz Operation, Inc.  All rights reserved.
1248 </small>
1249 </i>
1250 </html>