E.7 Object File Sections

We have worked with .data and .text program segments in sample programs, and have seen with the debugger that the linker assigns these to specific virtual address ranges. System software usually provides for additional logical sections that have some meaning to the programmer, the FORTRAN compiler, and so forth, but are ultimately just part of the .data or .text segments.

The Itanium assemblers provide an extension of the .section directive used also with GCC on other platforms. The particulars are discussed in the Intel Itanium Architecture Assembly Language Reference Manual. We shall illustrate only two forms:

 .section name, "flags", "type"  // define a section .section name                   // switch to a section 

In fact, we shall only use "a" as the flag for allocate (read-only) and "progbits" as the type in the illustrative macro in the next section.

Every object file section has its own location counter value that the assembler maintains with a distinct address origin associated with the section name. The names of object file sections, like the names of macros, are stored in a unique way within symbol tables during the assembly process and may thus duplicate macro names or symbols.

The binary object file produced by the assembler contains sufficient information to permit the linker to collect and organize all the fragments belonging to each section, and ultimately assign appropriate virtual address ranges in the .data or .text program segments.

The capability to specify numerous object file sections has been provided in the assembler for several reasons:

• to support the development of modular, more easily maintained programs;

• to protect instructions and read-only data from being modified;

• to prevent any attempted fetching of data as instructions; and

• to allow sharing of instructions (e.g., memory-resident shareable code libraries) or data in advanced applications.

Moreover, implementations of some high-level languages (e.g., FORTRAN) make use of sections for various "named" storage allocation regions.