Document revision date: 19 July 1999
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

OpenVMS Linker Utility Manual


Previous Contents Index

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 3-7.

The items in the following list correspond to the numbered items in Example 3-4:

  1. Alignment specifies the address boundary at which the linker places a module's contribution to the program section.
  2. 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 3-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 Digital. 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 3.4.3 describes how the linker creates demand-zero image sections.
  3. Allocation indicates the number of bytes required for the program section.
  4. Symbol indicates the name of the program section.

Figure 3-2 illustrates the program sections created by the VAX C compiler for the programs in Example 3-1, Example 3-2, and Example 3-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 3.3.3 for more information about how the linker creates image sections.)

Figure 3-2 Program Sections Created for Examples 3-1, 3-2, and 3-3


3.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 3.3.1 describes how the clustering of input files affects image section creation. Section 3.3.2 describes the effects of program section attributes on image section creation.

3.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 2.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 3.2 is shown in Example 3-5.

Example 3-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:

  1. MYSUB_CLUS
  2. VAXCRTL
  3. 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.)

3.3.2 Combining Program Sections into Image Sections

The linker creates image sections by grouping together program sections with similar attributes. Within an image section, the linker organizes program sections alphabetically by name. If more than one object module contributes to the same program section, the linker lays out their contributions in the order it processes them.

Figure 3-3 shows how the linker groups the program sections in the object modules from the sample link into image sections, based on the setting of their significant attributes. In the figure, the settings of these significant attributes are represented by shading. (The figure considers attributes that are significant when creating executable images, not shareable images. Section 3.3.3 provides more information about which program section attributes are significant.)

Note, in the figure, that the overlaid contributions from MYSUB.OBJ and MYTEST.OBJ to the program section, GLOBAL_DATA, both appear in the MYSUB_CLUS cluster, even though the object module MYTEST.OBJ is in the default cluster. The linker puts all contributions to a global program section in the cluster in which it is first defined.

Figure 3-3 Combining Program Sections into Image Sections


3.3.3 Processing Significant Program Section Attributes

When combining program sections into image sections, the linker considers only a subset of program section attributes. The set of significant attributes varies according to the type of image being created. When creating an executable image, the linker considers all combinations of the following attributes when combining program sections into image sections:

When creating a shareable image, the linker considers all combinations of the following attributes when combining program sections into image sections:

The linker creates only one large image section for system images, so combining program sections by attributes is not applicable.

Table 3-2 and Table 3-3 list all the possible combinations of program section attributes for executable images and shareable images. Note that the order in which the combinations appear in the table (each row) is the same order in which the linker processes them. For example, the linker first processes all program sections with the NOWRT, NOEXE, and NOVEC attributes, creating an image section of program sections with these attributes. The linker then processes all program sections with the WRT, NOEXE, and NOVEC attributes, creating an image section for these program sections. The linker continues this processing until all the combinations of significant attributes have been processed and all the program sections in the cluster have been placed in an image section.

The tables include only program sections that are relocatable (with the REL attribute). Absolute program sections (with the ABS attribute), by definition, can have no allocation (they contain only constants) and cannot contribute to an image section.

For OpenVMS Alpha images, the tables assume that the images are linked using the /DEMAND_ZERO qualifier, which is the default. (When this qualifier is specified, the linker groups program sections that do not contain any data into demand-zero image sections, allocating memory for the image section but not writing zeros to disk.) If the image is linked with the /NODEMAND_ZERO qualifier, the linker allocates space for the image section in the image file. Note that the /NODEMAND_ZERO qualifier does not affect how the linker sorts program sections; it proceeds exactly as specified by the table. However, when the image is written, the linker allocates disk space for the image section and fills the space with zeros.

The tables also show how a particular combination of program section attributes determines the attributes of the image section in which it is placed. For more information about image section attributes, see Section 3.3.5.

Table 3-2 Mapping Program Section Attributes to Image Section Attributes for Executable Images
Significant Psect Attribute Settings1 Type of Isect Isect Attributes Set2
NOWRT NOEXE NOVEC ++MOD NORMAL --
WRT NOEXE NOVEC ++MOD " WRT, CRF
NOWRT EXE NOVEC ++MOD " ++EXE
WRT EXE NOVEC ++MOD " WRT, CRF, ++EXE
NOWRT NOEXE VEC ++MOD " VECTOR,PROTECT
WRT NOEXE VEC ++MOD " WRT,VECTOR, PROTECT,CRF
NOWRT EXE VEC ++MOD " VECTOR,PROTECT, ++EXE
WRT EXE VEC ++MOD " WRT,VECTOR,PROTECT,++EXE
++NOWRT ++NOEXE ++NOVEC ++NOMOD " DZRO
++WRT ++NOEXE ++NOVEC ++NOMOD " WRT,DZRO 3


++Alpha specific
1For Alpha images, these attributes are prefixed with EGPS$V_. For VAX images, these attributes are prefixed with GPS$V_.
2For Alpha images, these attributes are prefixed with EISD$V_. For VAX images, these attributes are prefixed with ISD$V_.
3If the /NODEMAND_ZERO qualifier is specified, the copy-on-reference (CRF) attribute is set instead of the DZRO attribute.

Table 3-3 Mapping Program Section Attributes to Image Section Attributes for Shareable Images
Significant Psect Attribute Settings1 Type of Isect Isect Attributes Set2
NOWRT NOEXE SHR NOPIC NOVEC ++MOD SHRFXD --
WRT NOEXE SHR NOPIC NOVEC ++MOD " WRT
NOWRT EXE SHR NOPIC NOVEC ++MOD " ++EXE
WRT EXE SHR NOPIC NOVEC ++MOD " WRT,++EXE
               
NOWRT NOEXE NOSHR NOPIC NOVEC ++MOD PRVFXD --
WRT NOEXE NOSHR NOPIC NOVEC ++MOD " WRT, CRF
NOWRT EXE NOSHR NOPIC NOVEC ++MOD " ++EXE
WRT EXE NOSHR NOPIC NOVEC ++MOD " WRT,CRF,++EXE
               
NOWRT NOEXE SHR PIC NOVEC ++MOD SHRPIC PIC
WRT NOEXE SHR PIC NOVEC ++MOD " WRT, PIC
NOWRT EXE SHR PIC NOVEC ++MOD " PIC, ++EXE
WRT EXE SHR PIC NOVEC ++MOD " WRT,PIC,++EXE
               
NOWRT NOEXE NOSHR PIC NOVEC ++MOD PRVPIC PIC
WRT NOEXE NOSHR PIC NOVEC ++MOD " WRT, CRF, PIC
NOWRT EXE NOSHR PIC NOVEC ++MOD " PIC,++EXE
WRT EXE NOSHR PIC NOVEC ++MOD " WRT,CRF,PIC, ++EXE
               
NOWRT NOEXE SHR NOPIC VEC ++MOD SHRFXD VECTOR,PROTECT
WRT NOEXE SHR NOPIC VEC ++MOD " WRT,VECTOR,PROTECT
NOWRT EXE SHR NOPIC VEC ++MOD " VECTOR,PROTECT,++EXE
WRT EXE SHR NOPIC VEC ++MOD " WRT,VECTOR,PROTECT,
++EXE
               
NOWRT NOEXE NOSHR NOPIC VEC ++MOD PRVFXD VECTOR,PROTECT
WRT NOEXE NOSHR NOPIC VEC ++MOD " WRT, CRF
NOWRT EXE NOSHR NOPIC VEC ++MOD " VECTOR,PROTECT,++EXE
WRT EXE NOSHR NOPIC VEC ++MOD " WRT,CRF,VECTOR,
PROTECT, ++EXE
               
NOWRT NOEXE SHR PIC VEC ++MOD SHRPIC PIC,VECTOR,PROTECT
WRT NOEXE SHR PIC VEC ++MOD " WRT,PIC,VECTOR,
PROTECT
NOWRT EXE SHR PIC VEC ++MOD " PIC,VECTOR,PROTECT,
++EXE
WRT EXE SHR PIC VEC ++MOD " WRT,PIC,VECTOR,
PROTECT, ++EXE
               
NOWRT NOEXE NOSHR PIC VEC ++MOD PRVPIC PIC,VECTOR,PROTECT
WRT NOEXE NOSHR PIC VEC ++MOD " WRT,CRF,PIC,VECTOR, PROTECT
NOWRT EXE NOSHR PIC VEC ++MOD " PIC,VECTOR,PROTECT, ++EXE
WRT EXE NOSHR PIC VEC ++MOD " WRT,CRF,PIC,VECTOR, PROTECT,++EXE
               
++NOWRT ++NOEXE ++SHR ++NOPIC ++NOVEC ++NOMOD SHRFXD --
++WRT ++NOEXE ++SHR ++NOPIC ++NOVEC ++NOMOD " WRT
               
++NOWRT ++NOEXE ++NOSHR ++NOPIC ++NOVEC ++NOMOD PRVFXD DZRO
++WRT ++NOEXE ++NOSHR ++NOPIC ++NOVEC ++NOMOD " WRT,DZRO 3
               
++NOWRT ++NOEXE ++NOSHR ++PIC ++NOVEC ++NOMOD PRVPIC DZRO
++WRT ++NOEXE ++NOSHR ++PIC ++NOVEC ++NOMOD " WRT,DZRO 3, PIC
               
++NOWRT ++NOEXE ++SHR ++PIC ++NOVEC ++NOMOD SHRPIC PIC
++WRT ++NOEXE ++SHR ++PIC ++NOVEC ++NOMOD " WRT,PIC


++Alpha specific
1For Alpha images, these attributes are prefixed with EGPS$V_. For VAX images, these attributes are prefixed with GPS$V_.
2For Alpha images, these attributes are prefixed with EISD$V_. For VAX images, these attributes are prefixed with ISD$V_.
3If the /NODEMAND_ZERO qualifier is specified, the copy-on-reference (CRF) attribute is set instead of the DZRO attribute.

For example, Table 3-4 summarizes the settings of the significant attributes of the program sections in the module MYADD.OBJ. (Because this is an OpenVMS VAX object module, the MOD attribute is not considered.)

Table 3-4 Significant Attributes of Program Sections in MYSUB_CLUS Cluster
  Writability Executability Protected Vector
$CODE NOWRT EXE NOVEC
DATA WRT NOEXE NOVEC
$CHAR_STRING_CONSTANTS WRT NOEXE NOVEC


Previous Next Contents Index

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement  
4548PRO_006.HTML