HP OpenVMS Linker Utility Manual
Chapter 7
Understanding Image File Creation (Alpha and VAX)
This chapter describes how the linker creates an image on OpenVMS Alpha
and VAX systems. The linker creates images from the input files you
specify in a link operation. You can control image file creation by
using linker qualifiers and options.
7.1 Overview of Creating Images on Alpha/VAX Systems
After the linker has resolved all symbolic references between the input
files specified in the LINK command (described in Chapter 6), the
linker knows all the object modules and shareable images that are
required to create the image. For example, the linker has extracted
from libraries specified in the LINK command those modules that contain
the definitions of symbols required to resolve symbolic references in
other modules. The linker must now combine all these modules into an
image.
To create an image, the linker must perform the following processing:
After creating image sections and filling them with binary code and
data, the linker writes the image to an image file. Section 7.4.1
describes this process. To keep the size of image files manageable, the
linker does not allocate space in the image file for image sections
that have not been initialized with any data unless this function has
been disabled (that is, the linker does not write pages of zeros to the
image file). The linker can create demand-zero image
sections, which the operating system initializes at run time when a
reference to the image section requires the operating system to move
the pages into memory. Section 7.4.3 describes how the linker creates
demand-zero image sections.
7.2 Creating Program Sections (Alpha/VAX)
Language processors create program sections and define their
attributes. The number of program sections created by a language
processor and the attributes of these program sections are dependent
upon language semantics. For example, some programming languages
implement global variables as separate program sections with a
particular set of attributes. Programmers working in high-level
languages typically have little direct control over the program
sections created by the language processor. Medium- and low-level
languages provide programmers with more control over program section
creation. For more information about the program section creation
features of a particular programming language, see the language
processor documentation.
In general, the linker does not create program sections. However, for
Alpha linking, the linker creates a special program section for a
shareable image, named $SYMVECT, which contains the symbol vector of
the shareable image.
Program Section Attributes
The language processors define the attributes of the program sections
they create and communicate these attributes to the linker in program
section definition records in the global symbol directory (GSD) in an
object module. (The GSD also contains global symbol definitions and
references, as described in Chapter 6.)
Program section attributes control various characteristics of the area
of memory described by the program section, such as the following:
- Access. Using program section attributes,
compilers can prohibit some types of access, such as write access.
Using other program section attributes, compilers can allow access to
the program section by more than one process.
- Positioning. By specifying certain program section
attributes, compilers can specify to the linker how it should position
the program section in memory.
Program section attributes are Boolean values, that is, they are either
on or off. Table 7-1 lists all program section attributes with the
keyword you can use to set or clear the attribute, using the
PSECT_ATTR= option. (For more information about using the PSECT_ATTR=
option, see Section 7.3.6.)
For example, to specify that a program section should have write
access, specify the writability attribute as WRT. To turn off an
attribute, specify the negative keyword. Some attributes have separate
keywords that express the negative of the attribute. For example, to
turn off the global attribute (GBL), you must specify the local
attribute (LCL). Note that the alignment of a program section is not
strictly considered an attribute of the program section. However,
because you can set it using the PSECT_ATTR= option, it is included in
the table.
Table 7-1 Program Section Attributes (Alpha/VAX)
| Attribute |
Keyword |
Description |
|
Alignment
|
--
|
Specifies the alignment of the program section as an integer that
represents the power of 2 required to generate the desired alignment.
For certain alignments, the linker supports keywords to express the
alignment. The following table lists all the alignments supported by
the linker with their keywords:
| Power of 2 |
Keyword |
Meaning |
|
0
|
BYTE
|
Alignment on byte boundaries.
|
|
1
|
WORD
|
Alignment on word boundaries.
|
|
2
|
LONG
|
Alignment on longword boundaries.
|
|
3
|
QUAD
|
Alignment on quadword boundaries.
|
|
4
|
OCTA
|
Alignment on octaword boundaries.
|
|
9
|
--
|
Alignment on 512-byte boundaries.
|
|
13
|
--
|
Alignment on 8 KB boundaries.
|
|
14
|
--
|
Alignment on 16 KB boundaries.
|
|
15
|
--
|
Alignment on 32 KB boundaries.
|
|
16
|
--
|
Alignment on 64 KB boundaries.
|
|
--
|
PAGE
|
Alignment on the default target page size, which is 64 KB for Alpha
linking and 512 bytes for VAX linking. You can override this default by
specifying the /BPAGE qualifier.
|
|
|
Position Independence
|
PIC/NOPIC
|
Specifies that the program section can run anywhere in virtual address
space. Applicable in shareable images only. Note that this attribute is
not meaningful for Alpha images, but it is still used to sort program
sections.
|
|
Overlaid/Concatenated
|
OVR/CON
|
When set to OVR, specifies that the linker may combine (overlay) this
program section with other program sections with the same name and
attribute settings. Program sections that are overlaid are assigned the
same base address. When set to CON, the linker concatenates the program
sections.
|
|
Relocatable/Absolute
|
REL/ABS
|
When set to REL, specifies that the linker can place the program
section anywhere in virtual memory, according to the memory allocation
strategy for the type of image being produced. When set to ABS, this
attribute specifies that the program section is an absolute program
section that contains no binary data or code and appears to be based at
virtual address 0. Absolute program sections are used by compilers
primarily to define constants.
|
|
Global/Local
|
GBL/LCL
|
When set to GBL, specifies that the linker should gather contributions
to the program section
from all clusters and place them in the same image section.
When set to LCL, the linker gathers program sections into the same
image section only if they are in the same cluster. The memory for a
global program section is allocated in the cluster that contains the
first contributing module.
|
|
Shareability
|
SHR/NOSHR
|
Specifies that the program section can be shared between several
processes. Only used to sort program sections in shareable images.
|
|
Executability
|
EXE/NOEXE
|
Specifies that the program section contains executable code. If an
image transfer address is defined in a nonexecutable program section,
the linker issues a diagnostic message.
|
|
|
|
+For Alpha linking, the EXE attribute is propagated to the image
section descriptor where it is used by the Install utility when it is
installing the image as a resident image. (For information about
resident images, see the description of the /SECTION_BINDING qualifier
in Part 2.)
|
|
Writability
|
WRT/NOWRT
|
Specifies that the contents of a program section can be modified at run
time.
|
|
Protected Vectors
|
VEC/NOVEC
|
Specifies that the program section contains privileged change-mode
vectors or message vectors. In shareable images, image sections with
the VEC attribute are automatically protected.
|
|
Solitary
|
SOLITARY
|
Specifies that the linker should place this program section in its own
image section. Useful for programs that map data into specific
locations in their virtual memory space. Note that compilers do not set
this attribute. You can set this attribute using the PSECT_ATTR= option.
|
|
+Unmodified
|
NOMOD/MOD
|
When set, specifies that the program section has not been initialized
(NOMOD). On Alpha systems, the linker uses this attribute to create
demand zero sections; see Section 7.4.3. Only compilers can set this
attribute. You can clear this attribute only by specifying the MOD
keyword in the PSECT_ATTR= option.
|
|
+COM
|
--
|
Used by the Compaq C compiler to implement the relaxed symbol
reference/definition model for external variables. See the C
documentation for more information. This attribute cannot be modified
using the PSECT_ATTR= option.
|
|
Readability
|
RD
|
Reserved by HP.
|
|
User/Library
|
USR/LIB
|
Reserved by HP. To ensure future compatibility, this attribute should
be clear.
|
+Alpha specific
To illustrate program section creation, consider the program sections
created by the VAX C compiler when it processes the sample programs in
the following examples.
| Example 7-1 Sample Program MYTEST.C |
extern int global_data;
int myadd();
int mysub();
main()
{
int num1, num2, res1, res2;
static int my_data;
num1 = 5;
num2 = 6;
res1 = myadd( num1, num2 );
res2 = mysub( num1, num2 );
printf("res1 = %d, res2 =%d, globaldata=%d\n",
res1,res2,global_data);
}
|
| Example 7-2 Sample Program MYADD.C |
#include <stdio.h>
myadd(value_1,value_2)
int value_1;
int value_2;
{
int result;
static int add_data;
printf("In MYADD.C\n");
result = value_1 + value_2;
return( result );
}
|
| Example 7-3 Sample Program MYSUB.C |
int global_data = 5;
mysub(value_1,value_2)
int value_1;
int value_2;
{
int result;
static int sub_data;
result = value_1 - value_2;
return( result );
}
|
To see what program sections the VAX C compiler creates for these
programs, use the ANALYZE/OBJECT utility to examine the global symbol
directory (GSD) in each object module. (Note that the names the
language processors assign to program sections are architecture
specific.)
Example 7-4 presents an excerpt from the analysis of the object
module MYTEST.OBJ. Only the program section definitions are included in
the excerpt.
| Example 7-4 Program Sections Generated by
Example 3-1 |
4. GLOBAL SYMBOL DIRECTORY (OBJ$C_GSD), 138 bytes
.
.
.
6) Program Section Definition (GSD$C_PSC)
(1) alignment: 4-byte boundary <-- psect 0
(2) attribute flags:
(0) GPS$V_PIC 1
(1) GPS$V_LIB 0
(2) GPS$V_OVR 0
(3) GPS$V_REL 1
(4) GPS$V_GBL 0
(5) GPS$V_SHR 1
(6) GPS$V_EXE 1
(7) GPS$V_RD 1
(8) GPS$V_WRT 0
(9) GPS$V_VEC 0
(3) allocation: 63 (%X'0000003F')
(4) symbol: "$CODE"
7) Program Section Definition (GSD$C_PSC)
alignment: 4-byte boundary <-- psect 1
attribute flags:
(0) GPS$V_PIC 1
(1) GPS$V_LIB 0
(2) GPS$V_OVR 0
(3) GPS$V_REL 1
(4) GPS$V_GBL 0
(5) GPS$V_SHR 0
(6) GPS$V_EXE 0
(7) GPS$V_RD 1
(8) GPS$V_WRT 1
(9) GPS$V_VEC 0
allocation: 4 (%X'00000004')
symbol: "DATA"
8) Program Section Definition (GSD$C_PSC)
alignment: 4-byte boundary <-- psect 2
attribute flags:
(0) GPS$V_PIC 1
(1) GPS$V_LIB 0
(2) GPS$V_OVR 1
(3) GPS$V_REL 1
(4) GPS$V_GBL 1
(5) GPS$V_SHR 1
(6) GPS$V_EXE 0
(7) GPS$V_RD 1
(8) GPS$V_WRT 1
(9) GPS$V_VEC 0
allocation: 4 (%X'00000004')
symbol: "GLOBAL_DATA"
9) Program Section Definition (GSD$C_PSC)
alignment: 4-byte boundary <-- psect 3
attribute flags:
(0) GPS$V_PIC 1
(1) GPS$V_LIB 0
(2) GPS$V_OVR 0
(3) GPS$V_REL 1
(4) GPS$V_GBL 0
(5) GPS$V_SHR 0
(6) GPS$V_EXE 0
(7) GPS$V_RD 1
(8) GPS$V_WRT 1
(9) GPS$V_VEC 0
allocation: 36 (%X'00000024')
symbol: "$CHAR_STRING_CONSTANTS"
.
.
.
|
Note that you can also determine the program sections in an object
module after a link operation by looking at the Program
Section Synopsis section of an image map file, as illustrated in
Example 7-7.
The items in the following list correspond to the numbered items in
Example 7-4:
- Alignment specifies the address boundary at
which the linker places a module's contribution to the program section.
- Attribute flags indicate which program
section attributes are set. The attributes are listed by their full
symbolic name, that is, each abbreviation is preceded by the character
string "GPS$V_". Note that, for attributes that are turned
off by specifying different keywords, only the keyword that sets the
attribute is listed. For example, you can see whether the program
section is overlaid by checking attribute flag number 2. If the value
is 1, the program section is overlaid; if the value is 0, the program
section must be concatenated. Table 7-1 lists all the program
section attributes. Note that the solitary attribute is not included in
the GSD of an object module because that attribute is not set by
language processors.
For Alpha linking, the program section display
includes several additional attribute flags. The COM attribute is
reserved for use by Compaq. The NOMOD attribute indicates that the
program section does not contain initialized data. The linker gathers
program sections with this attribute into demand-zero image sections.
Section 7.4.3 describes how the linker creates demand-zero image
sections.
- Allocation indicates the number of bytes
required for the program section.
- Symbol indicates the name of the program
section.
Figure 7-2 illustrates the program sections created by the VAX C
compiler for the programs in Example 7-1, Example 7-2, and
Example 7-3. (The shaded areas represent the settings of the program
section attributes the linker considers when sorting the program
sections into image sections in an executable image. See Section 7.3.3
for more information about how the linker creates image sections.)
Figure 7-2 Program Sections Created for Examples 3-1, 3-2, and
3-3
7.3 Creating Image Sections
To create the image sections that define the memory requirements and
page protection characteristics of an image, the linker processes the
program section definitions in the object modules specified in the link
operation. The number and type of image sections the linker creates
depend on the number of clusters the linker creates when processing the
LINK command and on the attributes of the program sections in the
object modules in each cluster. Section 7.3.1 describes how the
clustering of input files affects image section creation. Section 7.3.2
describes the effects of program section attributes on image section
creation.
7.3.1 Processing Clusters to Create Image Sections
To create image sections, the linker processes the program section
definitions in the input files you specify in the LINK command. The
linker processes these input files on a cluster-by-cluster basis (as
described in Section 6.3.1).
In general, only program sections in a particular cluster can
contribute to a particular image section. However, the linker crosses
cluster boundaries when processing program sections with the global
(GBL) attribute. When the linker encounters a program section with the
global attribute, it searches all the previously processed clusters for
a program section with the same name and attributes and, if it finds
one, places the new definition of the global program section in the
same cluster as the first definition of the program section.
The linker processes input files in the order in which they appear in
the clusters, making two passes through the cluster list.
On its first pass, the linker processes based
clusters. Based clusters specify the location within memory at which
the linker must position them. A based cluster can be a cluster that
contains a based shareable image or a cluster, created by the CLUSTER=
option, in which a base address was specified.
For VAX linking, you can also use the BASE= option to specify the base
address of the default cluster.
For more information about creating based clusters, see the
descriptions of the CLUSTER= and BASE= options in Part 2.
After processing based clusters, the linker then processes nonbased
clusters. The linker ignores nonbased (position-independent) shareable
image clusters because they are allocated virtual memory at run time.
A LINK command to create an image using the object modules in
Section 7.2 is shown in Example 7-5.
| Example 7-5 Linking Examples 3-1, 3-2, and
3-3 |
$ LINK/MAP/FULL MYTEST, MYADD, SYS$INPUT/OPT
CLUSTER=MYSUB_CLUS,,,MYSUB
SYS$LIBRARY:VAXCRTL/SHARE
[Ctrl/Z]
|
The CLUSTER= option in this LINK command causes the linker to create a
cluster named MYSUB_CLUS, which contains the object module MYSUB.OBJ.
The linker also creates a cluster for the C Run-Time Library shareable
image VAXCRTL.EXE. The linker puts the object modules MYTEST.OBJ and
MYADD.OBJ in the default cluster. These clusters appear on the linker's
cluster list in the following order:
- MYSUB_CLUS
- VAXCRTL
- DEFAULT_CLUSTER
The linker always processes the default cluster last. (For Alpha
linking, you do not need to explicitly include the C Run-Time Library
shareable image in the link operation because it resides in the default
system shareable image library IMAGELIB.OLB, which the linker processes
by default.)
