Inside Macintosh: Mac OS Runtime Architectures /

Chapter 8 - PEF Structure

PEF Sections

A PEF container can contain any number of sections. A section usually contains code or data. A special case is the loader section, which is discussed separately in "The Loader Section" (page 8-15). For each section there is a header, which includes information such as the type of section, its presumed runtime address, its size, and so on, and a corresponding section contents area.

Sections are numbered from 0, based on the position of their header, and the sections are identified by these numbers. However, the corresponding section contents do not have to be in the same order as the section headers. The only requirement is that instantiated section headers (that is, headers for sections containing code or data) must precede noninstantiated ones in the section header array.

The section header data structure is of fixed size (28 bytes) and has the form shown in Listing 8-2.

Listing 8-2 Section header data structure

struct PEFSectionHeader {
   SInt32nameOffset;  
   UInt32defaultAddress; 
   UInt32totalSize;   
   UInt32unpackedSize; 
   UInt32packedSize;  
   UInt32containerOffset; 
   UInt8 sectionKind; 
   UInt8 shareKind;   
   UInt8 alignment;   
   UInt8 reservedA;   
};

The fields in the section header are as follows:

• The nameOffset field (4 bytes) holds the offset from the start of the section name table to the location of the section name. The name of the section is stored as a C-style null-terminated character string.

  If the section has no name, the nameOffset field contains -1.

• The defaultAddress field (4 bytes) indicates the preferred address (as designated by the linker) at which to place the section's instance. If the Code Fragment Manager can place the instance in the preferred memory location, the load-time and link-time addresses are identical and no internal relocations need to be performed.
• The totalSize field (4 bytes) indicates the size, in bytes, required by the section's contents at execution time. For a code section, this size is merely the size of the executable code. For a data section, this size indicates the sum of the size of the initialized data plus the size of any zero-initialized data. Zero-initialized data appears at the end of a section's contents and its length is exactly the difference of the totalSize and unpackedSize values.

  For noninstantiated sections, this field is ignored.

• The unpackedSize (4 bytes) is the size of the section's contents that is explicitly initialized from the container. For code sections, this field is the size of the executable code. For an unpacked data section, this field indicates only the size of the initialized data. For packed data this is the size to which the compressed contents expand. The unpackedSize value also defines the boundary between the explicitly initialized portion and the zero-initialized portion.

  For noninstantiated sections, this field is ignored.

• The packedSize field (4 bytes) indicates the size, in bytes, of a section's contents in the container. For code sections, this field is the size of the executable code. For an unpacked data section, this field indicates only the size of the initialized data. For a packed data section (see Table 8-1 (page 8-8)) this field is the size of the pattern description contained in the section.
• The containerOffset field (4 bytes) contains the offset from the beginning of the container to the start of the section's contents. Packed data sections and the loader section should be 4-byte aligned. Code sections and data sections that are not packed should be at least 16-byte aligned.
• The sectionKind field (1 byte) indicates the type of section as well as any special attributes. Table 8-1 (page 8-8) shows the currently supported section types. Note that instantiated read-only sections cannot have zero-initialized extensions.
• The shareKind field (1 byte) controls how the section information is shared among processes by the Code Fragment Manager. You can specify any of the sharing options shown in Table 8-2 (page 8-9).
• The alignment field (1 byte) indicates the desired alignment for instantiated sections in memory as a power of 2. A value of 0 indicates 1-byte alignment, 1 indicates 2-byte (halfword) alignment, 2 indicates 4-byte (word) alignment, and so on. Note that this field does not indicate the alignment of raw data relative to a container. The Code Fragment Manager does not support this field under System 7.

  In System 7, the Code Fragment Manager gives 16-byte alignment to all writable sections. The alignment of read-only sections, which are used directly from the container, is dependent on the alignment of the section's contents within the container and the overall alignment of the container itself. When the container is not file-mapped, the overall container alignment is 16 bytes. When the container is file-mapped, the entire data fork is mapped and aligned to a 4KB boundary. The overall alignment of a file-mapped container thus depends on the container's alignment within the data fork. Note that file-mapping is currently supported only on PowerPC machines, and only when virtual memory is enabled.

• The reservedA field (1 byte) is currently reserved and must be set to 0.

Table 8-1 shows the various types of sections that can appear in PEF containers and the corresponding value in the sectionKind field.

Table 8-1 Section types

Value	Type	Instantiated?	Description
0	Code	Yes	Contains read-only executable code in an uncompressed binary format. A container can have any number of code sections. Code sections are always shared.
1	Unpacked data	Yes	Contains uncompressed, initialized, read/write data followed by zero-initialized read/write data. A container can have any number of data sections, each with a different sharing option.
2	Pattern- initialized data	Yes	Contains read/write data initialized by a pattern specification contained in the section's contents. The contents essentially contain a small program that tells the Code Fragment Manager how to initialize the raw data in memory. A container can have any number of pattern-initialized data sections, each with its own sharing option. See "Pattern-Initialized Data" (page 8-10) for more information about creating pattern specifications.
3	Constant	Yes	Contains uncompressed, initialized, read-only data. A container can have any number of constant sections, and they are implicitly shared.
4	Loader	No	Contains information about imports, exports, and entry points. See "The Loader Section" (page 8-15) for more details. A container can have only one loader section.
5	Debug	N/A	Reserved for future use.
6	Executable data	Yes	Contains information that is both executable and modifiable. For example, this section can store code that contains embedded data. A container can have any number of executable data sections, each with a different sharing option.
7	Exception	N/A	Reserved for future use.
8	Traceback	N/A	Reserved for future use.

Table 8-2 shows the sharing options available for PEF sections and the corresponding value in the shareKind field.

Table 8-2 Sharing options

Type	Value	Description
Process share	1	Indicates that the section is shared within a process, but a fresh copy is created for different processes.
Global share	4	Indicates that the section is shared between all processes in the system.
Protected share	5	Indicates that the section is shared between all processes, but is protected. Protected sections are read/write in privileged mode and read-only in user mode. This option is not available in System 7.

---

Subtopics

The Section Name Table

Section Contents