Segment Declarations

A segment declaration creates a new segment in the a.out or changes the attribute values of an existing segment. (An existing segment is one that you previously defined or one of the three built-in segments described below.)

A segment declaration has the following syntax:

segment_name = {segment_attribute_value}*;

For each segment_name, you can specify any number of segment_attribute_values in any order, each separated by a space. (Only one attribute value is allowed for each segment attribute.) The segment attributes and their valid values are as follows:

There are three built-in segments with the following default attribute values:

• text (LOAD, ?RX, no virtual_address, physical_address, or length specified, alignment values set to defaults per CPU type)

• data (LOAD, ?RWX, no virtual_address, physical_address, or length specified, alignment values set to defaults per CPU type)

• note (NOTE)

The link-editor behaves as if these segments are declared before your mapfile is read in. See "Mapfile Option Defaults" for more information.

Note the following when entering segment declarations:

• A number can be hexadecimal, decimal, or octal, following the same rules as in the C language.

• No space is allowed between the V, P, L, R, or A and the number.

• The segment_type value can be either LOAD or NOTE.

• The segment_type value defaults to LOAD.

• The segment_flags values are R for readable, W for writable, X for executable, and O for order. No spaces are allowed between the question mark (?) and the individual flags that make up the segment_flags value.

• The segment_flags value for a LOAD segment defaults to RWX.

• NOTE segments cannot be assigned any segment attribute value other than a segment_type.

• Implicitly declared segments default to segment_type value LOAD, segment_flags value RWX, a default virtual_address, physical_address, and alignment value, and have no length limit.

  ---

  Note -

  The link-editor calculates the addresses and length of the current segment based on the previous segment's attribute values. Also, even though implicitly declared segments default to "no length limit," machine memory limitations still apply.

  ---

• LOAD segments can have an explicitly specified virtual_address value and/or physical_address value, as well as a maximum segment length value.

• If a segment has a segment_flags value of ? with nothing following, the value defaults to not readable, not writable, and not executable.

• The alignment value is used in calculating the virtual address of the beginning of the segment. This alignment only affects the segment for which it is specified; other segments still have the default alignment unless their alignments are also changed.

• If any of the virtual_address, physical_address, or length attribute values are not set, the link-editor calculates these values as it builds the a.out.

• If an alignment value is not specified for a segment, it is set to the built-in default. (The default differs from one CPU to another and might even differ between kernel versions. You should check the appropriate documentation for these numbers).

• If both a virtual_address and an alignment value are specified for a segment, the virtual_address value takes priority.

• If a virtual_address value is specified for a segment, the alignment field in the program header contains the default alignment value.

• If the rounding value is set for a segment, that segments virtual address will be rounded to the next address that conforms to the value given. This value only effects the segments that it is specified for. If no value is given, no rounding is performed.

The ?E flag allows the creation of an empty segment; this is a segment that has no sections associated with it. This segment can only be specified for executables, and must be of type LOAD with a specified size and alignment. Multiple segment definitions of this type are permitted.

The ?N flag lets you control whether the ELF header, and any program headers will be included as part of the first loadable segment. By default, the ELF header and program headers are included with the first segment, as the information in these headers is used within the mapped image (commonly by the runtime linker). The use of the ?N option causes the virtual address calculations for the image to start at the first section of the first segment.

The ?O flag lets you control the order of sections in the final relocatable object, executable file, or shared object. This flag is intended for use in conjunction with the -xF option to the compiler(s). When a file is compiled with the -xF option, each function in that file is placed in a separate section with the same attributes as the .text section. These sections are now called .text%function_name.

For example, a file containing three functions main(), foo() and bar(), when compiled with the -xF option, will yield an object file with text for the three functions in sections called .text%main, .text%foo, and .text%bar. Because the -xF option forces one function per section, the use of the ?O flag to control the order of sections in effect controls the order of functions.

Consider the following user-defined mapfile:

text = LOAD ?RXO;
text: .text%foo;
text: .text%bar;
text: .text%main;

If the order of function definitions in the source file is main, foo, and bar, then the final executable will contain functions in the order foo, bar, and main.

For static functions with the same name the file names must also be used. The ?O flag forces the ordering of sections as requested in the mapfile. For example, if a static function bar() exists in files a.o and b.o, and function bar() from file a.o is to be placed before function bar() from file b.o, then the mapfile entries should read:

text: .text%bar: a.o;
text: .text%bar: b.o;

Although the syntax allows for the entry:

text: .text%bar: a.o b.o;

this entry does not guarantee that function bar() from file a.o will be placed before function bar() from file b.o. The second format is not recommended as the results are not reliable.

If a virtual_address value is specified, the segment is placed at that virtual address. For the system kernel this creates a correct result. For files that start via exec(2), this method creates an incorrect a.out file because the segments do not have correct offsets relative to their page boundaries.