Segment Declarations
A segment declaration creates a new segment in the output file, or changes the attribute values of an existing segment. An existing segment is one that you previously defined or one of the four built-in segments described immediately following.
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 shown in the following table.
Table B-1 Mapfile Segment Attributes
Attribute | Value |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Four built-in segments exist with the following default attribute values.
-
text
–LOAD
,?RX
, novirtual_address
,physical_address
, orlength
specified.alignment
values are set to defaults per CPU type. -
data
–LOAD
,?RWX
, novirtual_address
,physical_address
, orlength
specified.alignment
values are set to defaults per CPU type. -
bss
– disabled,LOAD
,?RWX
, novirtual_address
,physical_address
, orlength
specified.alignment
values are set to defaults per CPU type. -
note
–NOTE
.
By default, the bss
segment is disabled. Any sections of type SHT_NOBITS
, which are its sole input, are captured in the data
segment. See ELF Section Types, sh_type for a full description of SHT_NOBITS
sections. The simplest bss
declaration is sufficient to enable the creation of a bss
segment.
bss =;
Any SHT_NOBITS
sections is captured by this segment, rather than captured in the data
segment. In its simplest form, this segment is aligned using the same defaults as applied to any other segment. The declaration can also provide additional segment attributes that both enable the segment creation, and assign the specified attributes.
The link-editor behaves as if these segments are declared before your mapfile
is read in. See Mapfile Option Defaults.
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
, orA
and the number. -
The
segment_type
value can be eitherLOAD
,NOTE
,NULL
orSTACK
. If unspecified, the segment type defaults toLOAD
. -
The
segment_flags
values areR
for readable,W
for writable,X
for executable, andO
for order. No spaces are allowed between the question mark (?
) and the individual flags that make up thesegment_flags
value. -
The
segment_flags
value for aLOAD
segment defaults toRWX
. -
NOTE
segments cannot be assigned any segment attribute value other than asegment_type
. -
One
segment_type
of valueSTACK
is permitted. Only the access requirements of the segment, selected from thesegment_flags
, can be specified. -
Implicitly declared segments default to
segment_type
valueLOAD
,segment_flags
valueRWX
, a defaultvirtual_address
,physical_address
, andalignment
value, and have nolength
limit.Note:
The link-editor calculates the addresses and length of the current segment based on the previous segment's attribute values. -
LOAD
segments can have an explicitly specifiedvirtual_address
value orphysical_address
value, as well as a maximum segmentlength
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 the alignment is specified. Other segments still have the default alignment unless theiralignment
values are also changed. -
If any of the
virtual_address
,physical_address
, orlength
attribute values are not set, the link-editor calculates these values as the output file is created. -
If an
alignment
value is not specified for a segment, the alignment is set to the built-in default. This default differs from one CPU to another and might even differ between software revisions. -
If both a
virtual_address
and analignment
value are specified for a segment, thevirtual_address
value takes priority. -
If a
virtual_address
value is specified for a segment, thealignment
field in the program header contains the default alignment value. -
If the
rounding
value is set for a segment, that segment's virtual address is rounded to the next address that conforms to the value that is given. This value only effects the segments that the value is specified for. If no value is given, no rounding is performed.
Note:
If avirtual_address
value is specified, the segment is placed at that virtual address. For the system kernel, this method creates a correct result. For files that start through
exec
(2), this method creates an incorrect output file because the segments do not have correct offsets relative to their page boundaries.
The ?E
flag allows the creation of an empty segment. This empty segment has no sections associated with the segment. This segment can be a LOAD
segment or a NULL
segment. Empty LOAD
segments can only be specified for executables. These segments must have a specified size and alignment. These segments result in the creation of memory reservations at process startup. Empty NULL
segments provide for adding program header entries that can be used by post-processing utilities. These segments should have no additional attributes specified. Multiple definitions for LOAD
segments and NULL
segments are permitted.
The ?N
flag enables you to control whether the ELF header, and any program headers are included as part of the first loadable segment. By default, the ELF header and program headers are included with the first segment. The information in these headers is used within the mapped image, typically 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 enables you control the order of sections in the output file. This flag is intended for use in conjunction with the -xF
option to the compilers. 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 called .text
%function_name.
For example, a file containing three functions, main
(), foo
() and bar
(), when compiled with the -xF
option, yields a relocatable object file with text for the three functions being placed 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;
The first declaration associates the ?O
flag with the default text segment.
If the order of function definitions in the source file is main
, foo
, and bar
, then the final executable contains 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 as follows.
text: .text%bar: a.o; text: .text%bar: b.o;
The syntax allows for the following entry.
text: .text%bar: a.o b.o;
However, this entry does not guarantee that function bar
() from file a.o
is placed before function bar
() from file b.o
. The second format is not recommended as the results are not reliable.