HP OpenVMS Systems Documentation

HP OpenVMS Linker Utility Manual

To create segments, the linker processes the 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).

Each cluster spawns segments into which sections are placed. However, the linker crosses cluster boundaries when processing sections with the global (GBL) attribute. (In ELF, GBL corresponds to SHF_VMS_GLOBAL.) When the linker encounters a section with the global attribute, it searches all the previously processed clusters for a section with the same name and attributes and, if it finds one, places the new definition of the global section in the same cluster as the first definition of the program section.

The linker processes input files in the order by which they appear in the clusters. Note that on I64 there are no based clusters, that is, the I64 linker does not allow you to enter a base address with the CLUSTER= option. In addition, the linker only has to process clusters once.

For more information about creating clusters, see the descriptions of the CLUSTER= and the COLLECT= option in Part 4.

A LINK command to create an image using the object modules in Section 3.2 is shown in Example 3-5.

$ LINK/MAP/FULL/CROSS MYTEST, MYADD, SYS$INPUT/OPT
CLUSTER=MYSUB_CLUS,,,MYSUB
[Ctrl/Z]

The CLUSTER= option in this link operation causes the linker to create a cluster named MYSUB_CLUS, which contains the object module MYSUB.OBJ. 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. DEFAULT_CLUSTER
3. DECC$SHR

The linker always processes the default cluster after any user-specified cluster (MYSUB_CLUS). DECC$SHR was automatically picked up from IMAGELIB.OLB by the I64 linker after the preceding clusters were processed and there were still unresolved symbols.

3.3.2 Combining Sections into Image Segments

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

Figure 3-5 shows how the linker groups the sections in the object modules from the sample link into segments, 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, and does not consider the SHR attribute as significant as it does with shareable images. Section 3.3.4 provides more information about which program section attributes are significant.)

Note that in Figure 3-5, the relaxed definition from MYTEST.OBJ for GLOBAL_DATA appears in the MYSUB_CLUS cluster, even though the object module MYTEST.OBJ is in the default cluster. In general, the linker puts all contributions to a global section in the cluster in which it is first defined. In the relaxed case, the linker chooses the memory from the hard definition that occurs in MYSUB.OBJ.

Figure 3-5 Combining Sections into Image Segments

Figure 3-6 continues the representation in Figure 3-5.

Figure 3-6 Combining Sections into Image Segments (continued)

1. The linker processes unwind tables and unwind information sections independent of the linker's general section collection rules. It groups all the .IA_64.unwind sections (which have section type SHT_IA_64_UNWIND) and then all the .IA_64.unwinfo sections follow linked in the same order as the code sections.

The ELF format has fewer attributes than a traditional OpenVMS image. Some of the attributes are expressed in the segment header and some are not used on I64 systems. In addition, the linker creates an image file in the ELF format. However, for compatibility, the I64 linker writes a map file with image attribute names the same as it does for other OpenVMS systems. Other utilities like ANALYZE/IMAGE simply display the ELF terms. To help explain ELF terms compared with traditional OpenVMS term, Table 3-3 shows how the terms are mapped.

When combining sections into segments, the linker considers only significant section atributes, that is, a subset of the 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 sections into segments:

• Writability (WRT/NOWRT)
• Executability (EXE/NOEXE)
• Protected vector (VEC/NOVEC)
• Unmodified (NOMOD/MOD)
• Short (SHORT/NOSHORT)
• Allocation in P2 (ALLOC_64BIT/NOALLOC_64BIT)

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

• Writability (WRT/NOWRT)
• Executability (EXE/NOEXE)
• Shareability (SHR/NOSHR)
• Protected vector (VEC/NOVEC)
• Unmodified (NOMOD/MOD)
• Short (SHORT/NOSHORT)
• Allocation in P2 (ALLOC_64BIT/NOALLOC_64BIT)

Table 3-4 and Table 3-5 list all the possible combinations of the significant 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 sections with the WRT, NOEXE, NOVEC, MOD, and NOSHORT attributes, creating a segment of sections with these attributes. The linker then processes all sections with the WRT, NOEXE, NOVEC, NOMOD and NOSHORT attributes, creating another segment for those sections. The linker continues this processing until all the combinations of significant attributes have been processed and all the sections in the cluster have been placed in a segment.

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

To simplify the tables, they do not include the ALLOC_64BIT attribute. ALLOC_64BIT only determines if the the section should be allocated in P2 space. The default is NOALLOC_64BIT. This attribute does not influence the segment attributes of the created segment. But obviously, two sections, whose attribute only differ in ALLOC_64BIT, end up in different segments. The ALLOC_64BIT attribute can be set for all sections except the ones with the SHORT attribute.

The linker creates additional segments that cannot be controlled by the user (see Section 3.4.3).

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 sections that do not contain any data into demand-zero segments, allocating memory for the segment but not writing zeros to disk.) If the image is linked with the /NODEMAND_ZERO qualifier, then the linker allocates space for the segment in the image file. Note that the /NODEMAND_ZERO qualifier does not affect how the linker sorts sections; it proceeds exactly as specified by the table. However, when the image is written, the linker allocates disk space for the segment and fills the space with zeros.

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

For example, Table 3-6 summarizes the settings of some significant attributes of the user controllable sections in the module MYSUB.OBJ (see Example 3-5).

The linker puts these four sections into three segments because only two have compatible attributes.

• The GLOBAL_DATA and SUB_DATA sections have identical attributes, including the WRT attribute.
• The $CODE$ and $LITERAL$ sections have the NOWRT attribute and differ in the EXE attribute.

The linker collects all these sections in segments in the named cluster MYSUB_CLUS, as requested with the CLUSTER= option in Example 3-5.

The linker performs similar processing of the sections in the default cluster in Example 3-5. The Image Segment Synopsis section of the map file lists the clusters the linker created and lists the segments it created for each cluster. This map section also describes the layout of the image in memory, including the base address of each segment within the image. Example 3-6 illustrates an excerpt of the Image Segment Synopsis section from the map file produced with the sample link (Example 3-5). Note that for I64, the listing does not include clusters for shareable images, like the HP C Run-Time Library.

                                   +------------------------+
                                   ! Image Segment Synopsis !
                                   +------------------------+

Seg#  Cluster            Type       Base Addr     Protection  Attributes
----  -------            ----       ---------     ----------  ----------
   0  MYSUB_CLUS         LOAD       00010000      READ WRITE
   1                     LOAD       00020000      READ ONLY   EXECUTABLE
   2                     LOAD       00030000      READ ONLY
   3                     LOAD       00040000      READ ONLY   [UNWIND] (1)(2)
   4  DEFAULT_CLUSTER    LOAD       00050000      READ WRITE
   5                     LOAD       00060000      READ ONLY   EXECUTABLE
   6                     LOAD       00070000      READ ONLY
   7                     LOAD       00080000      READ ONLY   [UNWIND] (1)(2)
   8                     LOAD       00090000      READ ONLY   SHORT (1)
   9                     DYNAMIC  Q-00000000
                                    80000000      READ ONLY (1)