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

   1 <html>
   2 <title>Program Header</title><p>
   3 <h1>Program Header</h1><p>
   4 An executable or shared object file's program header table
   5 is an array of structures, each describing a segment or
   6 other information the system needs to prepare the program for execution.
   7 An object file <i>segment</i> contains one or more <i>sections</i>,
   8 as
   9 <a href=#segment_contents>``Segment Contents''</a>
  10 describes below.
  11 Program headers are meaningful only for executable
  12 and shared object files.
  13 A file specifies its own program header size with the ELF header's
  14 <code>e_phentsize</code> and <code>e_phnum</code> members.
  15 See
  16 <a href=ch4.eheader.html>``ELF Header''</a> in Chapter 4
  17 for more information.
  18 <hr>
  19 <b>Figure 5-1: Program Header</b>
  20 <p>
  21 <pre>
  22 <code>
  23 typedef struct {
  24         Elf32_Word      p_type;
  25         Elf32_Off       p_offset;
  26         Elf32_Addr      p_vaddr;
  27         Elf32_Addr      p_paddr;
  28         Elf32_Word      p_filesz;
  29         Elf32_Word      p_memsz;
  30         Elf32_Word      p_flags;
  31         Elf32_Word      p_align;
  32 } Elf32_Phdr;
  33
  34 typedef struct {
  35         Elf64_Word      p_type;
  36         Elf64_Word      p_flags;
  37         Elf64_Off       p_offset;
  38         Elf64_Addr      p_vaddr;
  39         Elf64_Addr      p_paddr;
  40         Elf64_Xword     p_filesz;
  41         Elf64_Xword     p_memsz;
  42         Elf64_Xword     p_align;
  43 } Elf64_Phdr;
  44 </pre>
  45 </code>
  46 <dl compact>
  47 <p><dt><code>p_type</code><dd>
  48 This member tells what kind of segment this array element
  49 describes or how to interpret the array element's information.
  50 Type values and their meanings appear
  51 <a href=#p_type>below</a>.
  52 <p><dt><code>p_offset</code><dd>
  53 This member gives the offset from the beginning of the
  54 file at which the first byte of the segment resides.
  55 <p><dt><code>p_vaddr</code><dd>
  56 This member gives the virtual address at which
  57 the first byte of the segment resides in memory.
  58 <p><dt><code>p_paddr</code><dd>
  59 On systems for which physical addressing is relevant,
  60 this member is reserved for the segment's physical address.
  61 Because System V ignores physical addressing
  62 for application programs, this member has unspecified
  63 contents for executable files and shared objects.
  64 <p><dt><code>p_filesz</code><dd>
  65 This member gives the number of bytes in the file image of
  66 the segment; it may be zero.
  67 <p><dt><code>p_memsz</code><dd>
  68 This member gives the number of bytes in the memory image of
  69 the segment; it may be zero.
  70 <p><dt><code>p_flags</code><dd>
  71 This member gives flags relevant to the segment.
  72 Defined flag values appear
  73 <a href=#p_flags>below</a>.
  74 <p><dt><code>p_align</code><dd>
  75 As ``Program Loading'' describes in this chapter of the processor
  76 supplement,
  77 loadable process segments must have congruent values for
  78 <code>p_vaddr</code> and <code>p_offset</code>, modulo the page size.
  79 This member gives the value to which the
  80 segments are aligned in memory and in the file.
  81 Values 0 and 1 mean no alignment is required.
  82 Otherwise, <code>p_align</code>
  83 should be a positive, integral power of 2, and <code>p_vaddr</code>
  84 should equal <code>p_offset</code>,
  85 modulo <code>p_align</code>.
  86 </dl>
  87 <p>
  88 Some entries describe process segments; others
  89 give supplementary information and do not contribute to
  90 the process image.
  91 Segment entries may appear in any order, except as
  92 explicitly noted
  93 <a href=#p_type>below</a>.
  94 Defined type values follow;
  95 other values are reserved for future use.
  96 <a name="p_type"></a>
  97 <hr>
  98 <b>Figure 5-2: Segment Types</b>, <code>p_type</code>
  99 <p>
 100 <table border cellspacing=0>
 101 <th><b>Name</b></th>
 102 <th><b>Value</b></th>
 103 <tr>
 104 <td><code>PT_NULL</code></td>
 105 <td align=right><code>0</code></td>
 106 </tr>
 107 <tr>
 108 <td><code>PT_LOAD</code></td>
 109 <td align=right><code>1</code></td>
 110 </tr>
 111 <tr>
 112 <td><code>PT_DYNAMIC</code></td>
 113 <td align=right><code>2</code></td>
 114 </tr>
 115 <tr>
 116 <td><code>PT_INTERP</code></td>
 117 <td align=right><code>3</code></td>
 118 </tr>
 119 <tr>
 120 <td><code>PT_NOTE</code></td>
 121 <td align=right><code>4</code></td>
 122 </tr>
 123 <tr>
 124 <td><code>PT_SHLIB</code></td>
 125 <td align=right><code>5</code></td>
 126 </tr>
 127 <tr>
 128 <td><code>PT_PHDR</code></td>
 129 <td align=right><code>6</code></td>
 130 </tr>
 131 <tr>
 132 <td><code>PT_TLS</code></td>
 133 <td align=right><code>7</code></td>
 134 </tr>
 135 <tr>
 136 <td><code>PT_LOOS</code></td>
 137 <td align=right><code>0x60000000</code></td>
 138 </tr>
 139 <tr>
 140 <td><code>PT_HIOS</code></td>
 141 <td align=right><code>0x6fffffff</code></td>
 142 </tr>
 143 <tr>
 144 <td><code>PT_LOPROC</code></td>
 145 <td align=right><code>0x70000000</code></td>
 146 </tr>
 147 <tr>
 148 <td><code>PT_HIPROC</code></td>
 149 <td align=right><code>0x7fffffff</code></td>
 150 </tr>
 151 </table>
 152 <hr>
 153 <dl compact>
 154 <p><dt><code>PT_NULL</code><dd>
 155 The array element is unused; other members' values are undefined.
 156 This type lets the program header table have ignored entries.
 157 <p><dt><code>PT_LOAD</code><dd>
 158 The array element specifies a loadable segment,
 159 described by <code>p_filesz</code> and <code>p_memsz</code>.
 160 The bytes from the file are mapped to the
 161 beginning of the memory segment.
 162 If the segment's memory size (<code>p_memsz</code>)
 163 is larger than the file size (<code>p_filesz</code>),
 164 the ``extra'' bytes are defined to hold the value 0
 165 and to follow the segment's initialized area.
 166 The file size may not be larger than the memory size.
 167 Loadable segment entries in the program header table
 168 appear in ascending order, sorted on the <code>p_vaddr</code> member.
 169 <p><dt><code>PT_DYNAMIC</code><dd>
 170 The array element specifies dynamic linking information.
 171 See
 172 <a href=ch5.dynamic.html#dynamic_section>``Dynamic Section''</a>
 173 below for more information.
 174 <p><dt><code>PT_INTERP</code><dd>
 175 The array element specifies the location and size of
 176 a null-terminated path name to invoke as an interpreter.
 177 This segment type is meaningful only for executable files
 178 (though it may occur for shared objects);
 179 it may not occur more than once in a file.
 180 If it is present, it must precede any loadable segment entry.
 181 See
 182 <a href=ch5.dynamic.html#interpreter>``Program Interpreter''</a>
 183 below for more information.
 184 <p><dt><code>PT_NOTE</code><dd>
 185 The array element specifies the location and size of
 186 auxiliary information.
 187 See
 188 <a href=#note_section>``Note Section''</a>
 189 below for more information.
 190 <p><dt><code>PT_SHLIB</code><dd>
 191 This segment type is reserved but has unspecified semantics.
 192 Programs that contain an array element of this type do not
 193 conform to the ABI.
 194 <p><dt><code>PT_PHDR</code><dd>
 195 The array element, if present, specifies the location and size of
 196 the program header table itself, both in the file and
 197 in the memory image of the program.
 198 This segment type may not occur more than once in a file.
 199 Moreover, it may occur only if the program header table is
 200 part of the memory image of the program.
 201 If it is present, it must precede any loadable segment entry.
 202 See
 203 <a href=ch5.dynamic.html#interpreter>``Program Interpreter''</a>
 204 below for more information.
 205 <a name=pt_tls></a>
 206 <p><dt><code>PT_TLS</code><dd>
 207 The array element specifies the <i>Thread-Local Storage</i> template.
 208 Implementations need not support this program table entry.
 209 See <a href=#tls>``Thread-Local Storage''</a> below for more information.
 210 <p><dt><code>PT_LOOS</code> through <code>PT_HIOS</code>
 211 <dd>
 212 Values in this inclusive range
 213 are reserved for operating system-specific semantics.
 214 <p><dt><code>PT_LOPROC</code> through <code>PT_HIPROC</code>
 215 <dd>
 216 Values in this inclusive range
 217 are reserved for processor-specific semantics.
 218 If meanings are specified, the processor supplement explains
 219 them.
 220 </dl>
 221 <hr>
 222 <img src=warning.gif alt="NOTE:">
 223 Unless specifically required elsewhere,
 224 all program header segment types are optional.
 225 A file's program header table may contain
 226 only those elements relevant to its contents.
 227 <hr>
 228 <a name=base_address></a>
 229 <h2>Base Address</h2><p>
 230 As ``Program Loading'' in this chapter of the processor supplement
 231 describes, the virtual addresses in the program headers might not
 232 represent the actual virtual addresses of the program's memory
 233 image.  Executable files typically contain absolute code.  To let
 234 the process execute correctly, the segments must reside at the
 235 virtual addresses used to build the executable file.  On the other
 236 hand, shared object segments typically contain position-independent
 237 code.  This lets a segment's virtual address change from one
 238 process to another, without invalidating execution behavior.
 239 On some platforms, while the system chooses virtual
 240 addresses for individual processes,
 241 it maintains the <i>relative</i> position of one
 242 segment to another within any one shared object.
 243 Because position-independent code on those platforms
 244 uses relative addressing between segments,
 245 the difference between virtual addresses
 246 in memory must match the difference between virtual addresses
 247 in the file.  The differences between the virtual address
 248 of any segment in memory and the corresponding virtual address
 249 in the file is thus a single constant value for any one
 250 executable or shared object in a given process.  This difference
 251 is the <i>base address</i>.  One use of the base address is to
 252 relocate the memory image of the file during dynamic linking.
 253 <p>
 254 An executable or shared object file's base address (on platforms
 255 that support the concept)
 256 is calculated during execution
 257 from three values: the virtual memory load address, the maximum page size,
 258 and the lowest virtual address of a program's loadable segment.
 259 To compute the base address, one determines the memory address associated
 260 with the lowest <code>p_vaddr</code> value for a <code>PT_LOAD</code>
 261 segment.  This address is truncated to the nearest multiple of
 262 the maximum page size.  The corresponding <code>p_vaddr</code>
 263 value itself is also truncated to the nearest multiple of
 264 the maximum page size.  The base address is the difference
 265 between the truncated memory address and the truncated
 266 <code>p_vaddr</code> value.
 267 <p>
 268 See this chapter in the processor supplement for more information
 269 and examples.  ``Operating System Interface'' of Chapter 3
 270 in the processor supplement contains more information about the
 271 virtual address space and page size.
 272 <a name=segment_permissions></a>
 273 <h2>Segment Permissions</h2><p>
 274 A program to be loaded by the system must
 275 have at least one loadable segment (although
 276 this is not required by the file format).
 277 When the system creates loadable segments' memory images,
 278 it gives access permissions as specified in the <code>p_flags</code> member.
 279 <hr>
 280 <b>Figure 5-3: Segment Flag Bits, </b><code>p_flags</code>
 281 <p>
 282 <a name=p_flags></a>
 283 <table border cellspacing=0>
 284 <th><b>Name</b></th>
 285 <th><b>Value</b></th>
 286 <th><b>Meaning</b></th>
 287 <tr>
 288 <td><code>PF_X</code></td>
 289 <td align=right><code>0x1</code></td>
 290 <td>Execute</td>
 291 </tr>
 292 <tr>
 293 <td><code>PF_W</code></td>
 294 <td align=right><code>0x2</code></td>
 295 <td>Write</td>
 296 </tr>
 297 <tr>
 298 <td><code>PF_R</code></td>
 299 <td align=right><code>0x4</code></td>
 300 <td>Read</td>
 301 </tr>
 302 <tr>
 303 <td><code>PF_MASKOS</code></td>
 304 <td align=right><code>0x0ff00000</code></td>
 305 <td>Unspecified</td>
 306 </tr>
 307 <tr>
 308 <td><code>PF_MASKPROC</code></td>
 309 <td align=right><code>0xf0000000</code></td>
 310 <td>Unspecified</td>
 311 </tr>
 312 </table>
 313 <hr>
 314 All bits included in the <code>PF_MASKOS</code>
 315 mask are reserved for operating system-specific semantics.
 316 <p>
 317 All bits included in the <code>PF_MASKPROC</code>
 318 mask are reserved for processor-specific semantics.
 319 If meanings are specified, the processor supplement explains them.
 320 <p>
 321 If a permission bit is 0, that type of access is denied.
 322 Actual memory permissions depend on the memory management unit,
 323 which may vary from one system to another.
 324 Although all flag combinations are valid, the system may grant
 325 more access than requested.
 326 In no case, however, will a segment have write permission
 327 unless it is specified explicitly.
 328 The following table shows both the exact flag interpretation
 329 and the allowable flag interpretation. ABI-conforming systems may
 330 provide either.
 331 <hr>
 332 <b>Figure 5-4: Segment Permissions</b>
 333 <p>
 334 <table border cellspacing=0>
 335 <th><b>Flags</b></th>
 336 <th><b>Value</b></th>
 337 <th><b>Exact</b></th>
 338 <th><b>Allowable</b></th>
 339 <tr>
 340 <td><i>none</i></td>
 341 <td align=center><code>0</code></td>
 342 <td>All access denied</td>
 343 <td>All access denied</td>
 344 </tr>
 345 <tr>
 346 <td><code>PF_X</code></td>
 347 <td align=center><code>1</code></td>
 348 <td>Execute only</td>
 349 <td>Read, execute</td>
 350 </tr>
 351 <tr>
 352 <td><code>PF_W</code></td>
 353 <td align=center><code>2</code></td>
 354 <td>Write only</td>
 355 <td>Read, write, execute</td>
 356 </tr>
 357 <tr>
 358 <td><code>PF_W+PF_X</code></td>
 359 <td align=center><code>3</code></td>
 360 <td>Write, execute</td>
 361 <td>Read, write, execute</td>
 362 </tr>
 363 <tr>
 364 <td><code>PF_R</code></td>
 365 <td align=center><code>4</code></td>
 366 <td>Read only</td>
 367 <td>Read, execute</td>
 368 </tr>
 369 <tr>
 370 <td><code>PF_R+PF_X</code></td>
 371 <td align=center><code>5</code></td>
 372 <td>Read, execute</td>
 373 <td>Read, execute</td>
 374 </tr>
 375 <tr>
 376 <td><code>PF_R+PF_W</code></td>
 377 <td align=center><code>6</code></td>
 378 <td>Read, write</td>
 379 <td>Read, write, execute</td>
 380 </tr>
 381 <tr>
 382 <td><code>PF_R+PF_W+PF_X</code></td>
 383 <td align=center><code>7</code></td>
 384 <td>Read, write, execute</td>
 385 <td>Read, write, execute</td>
 386 </tr>
 387 </table>
 388 <hr>
 389 <p>
 390 For example, typical text segments have read and execute - but not write - permissions.
 391 Data segments normally have read, write, and execute permissions.
 392 <a name=segment_contents></a>
 393 <h2>Segment Contents</h2><p>
 394 An object file segment comprises one or more sections,
 395 though this fact is transparent to the program header.
 396 Whether the file segment holds one or many sections
 397 also is immaterial to program loading.
 398 Nonetheless, various data must be present for program
 399 execution, dynamic linking, and so on.
 400 The diagrams below illustrate segment contents in general terms.
 401 The order and membership of sections within a segment may vary;
 402 moreover, processor-specific constraints may alter the
 403 examples below.  See the processor supplement for details.
 404 <p>
 405 Text segments contain read-only instructions and data,
 406 typically including the following sections described in Chapter 4.
 407 Other sections may also reside in loadable segments;
 408 these examples are not meant to give complete and
 409 exclusive segment contents.
 410 <hr>
 411 <b>Figure 5-5: Text Segment</b>
 412 <p>
 413 <table border cellspacing=0>
 414 <tr><td align=center><code>.text</code></td></tr>
 415 <tr><td align=center><code>.rodata</code></td></tr>
 416 <tr><td align=center><code>.hash</code></td></tr>
 417 <tr><td align=center><code>.dynsym</code></td></tr>
 418 <tr><td align=center><code>.dynstr</code></td></tr>
 419 <tr><td align=center><code>.plt</code></td></tr>
 420 <tr><td align=center><code>.rel.got</code></td></tr>
 421 </table>
 422 <hr>
 423 <p>
 424 Data segments contain writable data and instructions,
 425 typically including the following sections.
 426 <hr>
 427 <b>Figure 5-6: Data Segment</b>
 428 <p>
 429 <table border cellspacing=0>
 430 <tr><td align=center><code>.data</code></td></tr>
 431 <tr><td align=center><code>.dynamic</code></td></tr>
 432 <tr><td align=center><code>.got</code></td></tr>
 433 <tr><td align=center><code>.bss</code></td></tr>
 434 </table>
 435 <hr>
 436 <p>
 437 A <code>PT_DYNAMIC</code> program header element points at the <code>.dynamic</code>
 438 section, explained in
 439 <a href=ch5.dynamic.html#dynamic_section>``Dynamic Section''</a>
 440 below.
 441 The <code>.got</code> and <code>.plt</code>
 442 sections also hold information related to position-independent
 443 code and dynamic linking.
 444 Although
 445 the <code>.plt</code>
 446 appears in a text segment in the previous table, it
 447 may reside in a text or a data segment,
 448 depending on the processor.
 449 See ``Global Offset Table'' and ``Procedure Linkage Table''
 450 in this section of the processor supplement for details.
 451 <p>
 452 As
 453 <a href=ch4.sheader.html>``Sections''</a>
 454 in Chapter 4 describes,
 455 the <code>.bss</code> section has the type <code>SHT_NOBITS</code>.
 456 Although it occupies no space in the file, it contributes
 457 to the segment's memory image.
 458 Normally, these uninitialized data reside at the end of
 459 the segment, thereby making <code>p_memsz</code> larger
 460 than <code>p_filesz</code>
 461 in the associated program header element.
 462 <a name=note_section></a>
 463 <h2>Note Section</h2>
 464 Sometimes a vendor or system builder needs to mark an
 465 object file with special information that
 466 other programs will check for conformance, compatibility, etc.
 467 Sections of type <code>SHT_NOTE</code>
 468 and program header elements of type
 469 <code>PT_NOTE</code> can be used for this purpose.
 470 The note information in sections and
 471 program header elements holds a variable amount of entries.
 472 In 64-bit objects (files with <code>e_ident[EI_CLASS]</code> equal to
 473 <code>ELFCLASS64</code>),
 474 each entry is an array of 8-byte words in the format of
 475 the target processor.
 476 In 32-bit objects (files with <code>e_ident[EI_CLASS]</code> equal to
 477 <code>ELFCLASS32</code>),
 478 each entry is an array of 4-byte words in the format of
 479 the target processor.
 480 Labels appear below
 481 to help explain note information
 482 organization, but they are not part of the specification.
 483 <hr>
 484 <b>Figure 5-7: Note Information</b>
 485 <p>
 486 <table border cellspacing=0>
 487 <tr><td align=center><code>namesz</code></td></tr>
 488 <tr><td align=center><code>descsz</code></td></tr>
 489 <tr><td align=center><code>type</code></td></tr>
 490 <tr><td align=center><code>name<br>. . .</code></td></tr>
 491 <tr><td align=center><code>desc<br>. . .</code></td></tr>
 492 </table>
 493 <hr>
 494 <dl>
 495 <dt><code>namesz</code> and <code>name</code>
 496 <dd>
 497 The first <code>namesz</code> bytes in <code>name</code>
 498 contain a null-terminated character representation
 499 of the entry's owner or originator.
 500 There is no formal mechanism for avoiding name conflicts.
 501 By convention, vendors use their own name, such as
 502 <code>XYZ Computer Company</code>, as the identifier.
 503 If no name is present, <code>namesz</code> contains 0.
 504 Padding is present, if necessary, to ensure 8 or 4-byte
 505 alignment for the descriptor (depending on whether the
 506 file is a 64-bit or 32-bit object).
 507 Such padding is not included in <code>namesz</code>.
 508 <p><dt><code>descsz</code> and <code>desc</code>
 509 <dd>
 510 The first <code>descsz</code> bytes in <code>desc</code>
 511 hold the note descriptor.  The ABI places no constraints on a
 512 descriptor's contents.
 513 If no descriptor is present, <code>descsz</code>
 514 contains 0.
 515 Padding is present, if necessary, to ensure 8 or 4-byte
 516 alignment for the next note entry (depending on whether the
 517 file is a 64-bit or 32-bit object).
 518 Such padding is not included in <code>descsz</code>.
 519 <p><dt><code>type</code>
 520 <dd>
 521 This word gives the interpretation of the descriptor.
 522 Each originator controls its own types; multiple
 523 interpretations of a single type value may exist.
 524 Thus, a program must recognize both the name and
 525 the type to recognize a descriptor.
 526 Types currently must be non-negative.
 527 The ABI does not define what descriptors mean.
 528 </dl>
 529 <p>
 530 To illustrate, the following note segment holds two entries.
 531 <hr>
 532 <b>Figure 5-8: Example Note Segment</b>
 533 <p>
 534 <table>
 535 <td>
 536 <table>
 537 <tr><td><br></td></tr>
 538 <tr><td><code>namesz</code></td></tr>
 539 <tr><td><code>descsz</code></td></tr>
 540 <tr><td><code>type</code></td></tr>
 541 <tr><td><code>name</code></td></tr>
 542 <tr><td><br></td></tr>
 543 <tr><td><code>namesz</code></td></tr>
 544 <tr><td><code>descsz</code></td></tr>
 545 <tr><td><code>type</code></td></tr>
 546 <tr><td><code>name</code></td></tr>
 547 <tr><td><br></td></tr>
 548 <tr><td><code>desc</code></td></tr>
 549 <tr><td><br></td></tr>
 550 </table>
 551 </td>
 552 <td>
 553 <table border cellspacing=0>
 554 <th width=40><b>+0</b></th>
 555 <th width=40><b>+1</b></th>
 556 <th width=40><b>+2</b></th>
 557 <th width=40><b>+3</b></th>
 558 <tr><td colspan=4 align=center><code>7</code></td></tr>
 559 <tr><td colspan=4 align=center><code>0</code></td></tr>
 560 <tr><td colspan=4 align=center><code>1</code></td></tr>
 561 <tr>
 562 <td><code>x</code></td>
 563 <td><code>y</code></td>
 564 <td><code>z</code></td>
 565 <td>&nbsp</td>
 566 </tr>
 567 <tr>
 568 <td><code>c</code></td>
 569 <td><code>o</code></td>
 570 <td><code>\0</code></td>
 571 <td><i>pad</i></td>
 572 </tr>
 573 <tr><td colspan=4 align=center><code>7</code></td></tr>
 574 <tr><td colspan=4 align=center><code>8</code></td></tr>
 575 <tr><td colspan=4 align=center><code>3</code></td></tr>
 576 <tr>
 577 <td><code>x</code></td>
 578 <td><code>y</code></td>
 579 <td><code>z</code></td>
 580 <td>&nbsp</td>
 581 </tr>
 582 <tr>
 583 <td><code>c</code></td>
 584 <td><code>o</code></td>
 585 <td><code>\0</code></td>
 586 <td><i>pad</i></td>
 587 <tr><td colspan=4 align=center><i>word 0</i></td></tr>
 588 <tr><td colspan=4 align=center><i>word 1</i></td></tr>
 589 </tr>
 590 </table>
 591 </td>
 592 <td>
 593 <table>
 594 <tr><td><br></td></tr>
 595 <tr><td>No descriptor</td></tr>
 596 <tr><td><br></td></tr>
 597 <tr><td><br></td></tr>
 598 <tr><td><br></td></tr>
 599 <tr><td><br></td></tr>
 600 <tr><td><br></td></tr>
 601 <tr><td><br></td></tr>
 602 <tr><td><br></td></tr>
 603 <tr><td><br></td></tr>
 604 <tr><td><br></td></tr>
 605 <tr><td><br></td></tr>
 606 </table>
 607 </td>
 608 </table>
 609 <hr>
 610 <img src=warning.gif alt="NOTE:">
 611 The system reserves note information with no name
 612 (<code>namesz==0</code>) and with a zero-length name
 613 (<code>name[0]=='\0'</code>) but currently defines no types.
 614 All other names must have at least one non-null character.
 615 <hr>
 616 <img src=warning.gif alt="NOTE:">
 617 Note information is optional.  The presence of note information
 618 does not affect a program's ABI conformance, provided the
 619 information does not affect the program's execution behavior.
 620 Otherwise, the program does not conform to the ABI and has
 621 undefined behavior.
 622 <hr>
 623 <a name=tls></a>
 624 <h2>Thread-Local Storage</h2>
 625 To permit association of separate copies of data allocated at compile-time
 626 with individual threads of execution,
 627 thread-local storage sections
 628 can be used to specify the size and initial contents of such data.
 629 Implementations need not support thread-local storage.
 630 A <code>PT_TLS</code> program entry has the following members:
 631 <table border cellspacing=0>
 632 <th><b>Member</b></th>
 633 <th><b>Value</b></th>
 634 <tr>
 635 <td><code>p_offset</code></td>
 636 <td align=left>File offset of the TLS initialization image</td>
 637 </tr>
 638 <tr>
 639 <td><code>p_vaddr</code></td>
 640 <td align=left>Virtual memory address of the TLS initialization image</td>
 641 </tr>
 642 <tr>
 643 <td><code>p_paddr</code></td>
 644 <td align=left>reserved</td>
 645 </tr>
 646 <tr>
 647 <td><code>p_filesz</code></td>
 648 <td align=left>Size of the TLS initialization image</td>
 649 </tr>
 650 <tr>
 651 <td><code>p_memsz</code></td>
 652 <td align=left>Total size of the TLS template</td>
 653 </tr>
 654 <tr>
 655 <td><code>p_flags</code></td>
 656 <td align=left><code>PF_R</code></td>
 657 </tr>
 658 <tr>
 659 <td><code>p_align</code></td>
 660 <td align=left>Alignment of the TLS template</td>
 661 </tr>
 662 </table>
 663 <p>
 664 The <i>TLS template</i> is formed from the combination
 665 of all sections with the flag <code>SHF_TLS</code>.
 666 The portion of the TLS template that holds initialized data
 667 is the <i>TLS initialization image</i>.
 668 (The remaining portion of the TLS template
 669 is one or more sections of type <code>SHT_NOBITS</code>.)
 670 <hr>
 671 <a href=ch5.intro.html><img src=previous.gif alt="Previous"></a>
 672 <a href=contents.html><img src=contents.gif alt="Contents"></a>
 673 <a href=ch5.prog_loading.html><img src=next.gif alt="Next"></a>
 674 <hr>
 675 <i>
 676 <small>
 677 &#169; 1997, 1998, 1999, 2000, 2001 The Santa Cruz Operation, Inc.  All rights reserved.
 678 </small>
 679 </i>
 680 </html>