HP OpenVMS Systems Documentation

HP OpenVMS Linker Utility Manual

When it creates an image section, the linker allocates enough memory for the image section to accommodate all the program sections it contains. Each program section definition includes its size.

The linker aligns image sections on CPU-specific page boundaries. Within an image section, the linker assigns to each program section a virtual address relative to the base address of the image section.

Concatenated Program Sections

If the program sections have the concatenated (CON) attribute set, the linker positions the program sections one after the other within an image section, inserting padding bytes between the program sections if necessary to achieve the alignment requirement of a particular contribution to a program section. The linker retains the alignment specified for each program section contribution but uses the largest alignment of a contributing module as the alignment of the whole program section.

Overlaid Program Sections

If the program sections have the overlaid (OVR) attribute set, the linker uses the same start address for the program sections so that they occupy the same virtual memory (that is, the program sections overlay each other). For overlaid program sections, the linker allocates enough space to accommodate the largest of all the program section contributions. Note that the linker does not generate a warning message if the contributions specify different size allocations.

Any module can initialize the contents of an overlaid program section. However, the final contents of the program section are determined by the last contributing module. Therefore, the order in which you specify the input modules is important.

Assigning Virtual Addresses

The linker keeps track of free (available) virtual addresses by maintaining a free virtual memory list. For each cluster, the linker determines the number of pages required, searches the list beginning at the lowest virtual address for a contiguous number of pages large enough to contain the cluster, allocates those addresses to the cluster, then removes those addresses from the list.

The linker allocates virtual memory to the first cluster beginning at a page size boundary for executable images in the P0 region of the user's virtual address space, unless the cluster is based, in which case it allocates virtual memory beginning at the specified address. For VAX linking, the default is 512 (200 hexadecimal). However, you can specify the page size using the /BPAGE qualifier. (For information about the /BPAGE qualifier, see Part 2.)

On its first pass through the cluster list, the linker allocates virtual addresses to any based user clusters or based shareable image clusters on the cluster list, removing the allocated addresses from the free virtual memory list as it proceeds. On its second pass, it repeats this procedure for nonbased user clusters. (Remember that nonbased shareable image clusters will have memory allocated for them at run time.)

Because the linker processes clusters in the order of their appearance on the cluster list, the virtual address space of the final image will generally contain contiguous image sections of consecutive clusters on the basis of their order in the cluster list. The presence of based clusters, however, may prevent such an outcome, and for this reason they are not recommended.

After allocating memory for a cluster, the linker relocates its contents by performing the following processing:

1. Relocating each image section. The linker adds the starting virtual address of the cluster to the relative offset of the image section from the cluster base and places the result in the appropriate field of the image section descriptor (ISD).
2. Relocating each program section in the image section. The linker adds the newly calculated starting virtual address of the image section to the relative offset of the program section from the base of the image section.
3. Relocating each global symbol in the program section. The linker adds the newly calculated program section virtual address to the relative offset of the global symbols from the base of the program section.

When it creates image sections, the linker assigns attributes to the image section based on the attributes of the program sections it contains. The image section attributes describe certain characteristics of the portion of memory they represent, for example, the protection characteristics. For example, an image section that contains program sections with the writability attribute also has the writability attribute set. Table 7-2 and Table 7-3 include the image section attributes associated with an image section that contains program sections with a particular set of attributes. Table 7-5 lists all the image section attributes. Image section attributes, like program section attributes, are Boolean values that are either on or off.

The linker uses type designations instead of image section attributes to propagate the SHR and PIC program section attributes. The linker assigns the type designation [E]ISD$K_NORMAL for image sections in executable images. Image sections in shareable images can be any of the following types:

The Image Section Synopsis section of a map file lists the attributes of each image section created in the Protection and Paging column. See Example 7-6 for an illustration. You can also get a listing of all the image sections created by the linker by using the ANALYZE/IMAGE utility. The output generated by this utility includes a list of all the image sections that make up the image, with their attributes. An excerpt from the analysis of the image file MYTEST.EXE is shown in Example 7-8.

 Image Section Descriptors (ISD)

  1)(1)  image section descriptor (16 bytes)
    (2) page count: 1
    (3) base virtual address: %X'00000200' (P0 space)
    (4) page fault cluster size: default
    (5) IS flags:
    (0)  ISD$V_GBL        0
    (1)  ISD$V_CRF        1
    (2)  ISD$V_DZRO       0
    (3)  ISD$V_WRT        1
    (7)  ISD$V_LASTCLU    0
    (8)  ISD$V_INITALCODE 0
    (9)  ISD$V_BASED      0
    (10) ISD$V_FIXUPVEC   0
    (11) ISD$V_RESIDENT   0
    (17) ISD$V_VECTOR     0
    (18) ISD$V_PROTECT    0
    (6) section type: ISD$K_NORMAL
    (7) base VBN: 2
                        .
                        .
                        .
  9)  image section descriptor (31 bytes)
   page count: 193
   base virtual address: %X'00000000' (P0 space)
   page fault cluster size: default
   IS flags:
    (0)  ISD$V_GBL        1
    (1)  ISD$V_CRF        0
    (2)  ISD$V_DZRO       0
    (3)  ISD$V_WRT        0
    (7)  ISD$V_LASTCLU    0
    (8)  ISD$V_INITALCODE 0
    (9)  ISD$V_BASED      0
    (10) ISD$V_FIXUPVEC   0
    (11) ISD$V_RESIDENT   0
    (17) ISD$V_VECTOR     0
    (18) ISD$V_PROTECT    0
   section type: ISD$K_SHRPIC
   base VBN: 0
  (8) global section major id: %X'01', minor id: %X'00000E'
  (9) match control: ISD$K_MATLEQ
  (10) global section name: "LIBRTL_001"

The items in the following list correspond to the numbers in Example 7-8:

1. The size of the image section descriptor.
2. The size of the image section, expressed in pages. For Alpha images, the value is expressed in bytes.
3. The start address assigned to the image section by the linker. Note that this address is an offset from the beginning of the image, which is assumed to start at virtual address zero. (The linker always inserts an empty page at the beginning of every executable image.) Note also that the linker does not assign a start address for image sections representing shareable images because this information cannot be determined until run time, when the shareable image is loaded into memory by the image activator.
4. The number of pagelets that should be mapped in when the initial page fault occurs. You can set this value by using the CLUSTER= option.
5. The settings of image section attributes. Table 7-5 lists these attributes.
6. The type of image section, based on the combination of image section attributes.
7. The virtual block in the image file at which the image section begins.
8. Image sections that represent shareable images include the global section identification number, which specifies the identification number of the shareable image.
9. Image sections that represent shareable images also include a match control field that identifies the match control algorithm the image activator should apply to the global image section identification number when it activates the shareable image this ISD describes.
10. Image sections that represent shareable images include the global section name field, which is the name of the shareable image. The "_001"" is appended to the name by the linker to indicate which ISD in the image this represents.

You can control how the linker combines program sections into image sections in the following ways:

• By modifying the attributes of program sections
• By putting object modules into named clusters
• By using the SOLITARY attribute

The linker combines program sections in the same cluster into the same image section if they have the same settings for the significant program section attributes. To force the linker to put the program sections into different image sections, change the attributes of one of the program sections by using the PSECT_ATTR= option.

For example, in the sample link operation, the DATA program section and the $CHAR_STRING_CONSTANTS program section are combined into the same image section. If you want the $CHAR_STRING_CONSTANTS program section to appear in a different image section, change one of the significant attributes. For example, in the following link of the sample programs, the writability attribute is set to NOWRT. (For Alpha linking, you do not need to explicitly specify the C Run-Time Library in the link operation because it resides in the default system shareable image library [IMAGELIB.OLB], which the linker processes by default.)

$ LINK/MAP/FULL MYTEST,MYADD,SYS$INPUT/OPT
CLUSTER=MYSUB_CLUS,,,MYSUB
PSECT_ATTR=$CHAR_STRING_CONSTANTS,NOWRT
SYS$LIBRARY:VAXCRTL/SHARE
[Ctrl/Z]

Example 7-9 presents an excerpt from the Image Section Synopsis section of the map file produced by this link.

   Cluster    Type Pages Base Addr Disk VBN PFC Protection and Paging...
   -------    ---- ----- --------- -------- --- ---------------------
                .
                .
                .
DEFAULT_CLUSTER 0    1    00000600      4    0  READ ONLY
                0    1    00000800      0    0  READ WRITE   DEMAND ZERO
                0    1    00000A00      5    0  READ ONLY
                0    1    00000C00      6    0  READ WRITE   FIXUP VECTORS
              253   20    7FFFD800      0    0  READ WRITE   DEMAND ZERO
                .
                .
                .

Note that the default cluster contains one additional image section, a read-only image section beginning at virtual address 0x00000600, than the default cluster in the original link, illustrated in Section 7.3.1.

7.3.6.2 Manipulating Cluster Creation

In general, the linker creates image sections on a per-cluster basis; that is, only program sections within a particular cluster can contribute to image section creation. (The linker can collect program sections with the global attribute from all clusters into a single image section.) To ensure that a program section appears in a particular image section, put the program section in a specific cluster.

For example, in the sample link operation illustrated in Example 7-5, the linker puts all the program sections in the object module MYSUB.OBJ in the cluster named MYSUB_CLUS because the CLUSTER= option is specified. If you wanted to group all of the program sections that contain code from all the other clusters into the MYSUB_CLUS cluster, you could specify the COLLECT= option, as in the following example. (By convention, VAX language processors put the code they generate into program sections named $CODE. Program section naming conventions are architecture specific.)

$ LINK/MAP/FULL MYTEST, MYADD, SYS$INPUT/OPT
CLUSTER=MYSUB_CLUS,,,MYSUB
COLLECT=MYSUB_CLUS,$CODE
SYS$LIBRARY:VAXCRTL/SHARE
[Ctrl/Z]

You can specify that the linker place a particular program section into its own image section. This can be useful for programs that map data into predefined locations within an image.

To isolate a program section into an image section, specify the SOLITARY attribute of the program section using the PSECT_ATTR= option. For example, to isolate the GLOBAL_DATA program section in the sample link into its own image section, specify the following:

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

For Alpha linking, when mapping data into an existing location in the virtual memory of your program using the Create and Map Global Section ($CRMPSC) system service or the Map Global Section ($MGBLSC) system service, you must specify an address range (in the inadr argument) that is aligned on a CPU-specific page boundary. Because the linker aligns image sections on CPU-specific page boundaries and the program section in which the section is to be mapped is the only program section in the image section, you ensure that the start address of the location is page aligned. In addition, because Alpha systems must map at least an entire page of memory at a time, using the SOLITARY attribute allows you to ensure that no other data in the image section is inadvertently overwritten by the mapping. By default, the linker creates the next image section on the next page boundary so that no data can be overwritten.

7.4 Initializing an Image on Alpha/VAX Systems

After allocating memory for the image, the linker initializes the image by writing the binary contents of the image sections by processing text information and relocation (TIR) records in the object modules. These records direct the linker in the initialization of the image section by telling it what to store in the image section buffers. In addition, the linker inserts the addresses of symbols within the image wherever they are referenced.

7.4.1 Writing the Binary Contents of Image Sections

A TIR record contains object language commands, such as stack and store commands. Stack commands direct the linker to put information on its stack, and store commands direct the linker to write the information from its stack to the buffer for that image section.

During this image section initialization, the linker keeps track of the program section being initialized and the image section to which it has been allocated. The first attempt to initialize part of an image section by storing nonzero data causes the linker to allocate a buffer in its own program region to contain the binary contents of the generated image section. This allocation is achieved by the Expand Region ($EXPREG) system service, and it requires that the linker have available a virtually contiguous region of its own memory at least as large as the image section being initialized.

A buffer is not allocated for an image section until the linker executes a store command (with nonzero data) within that image section.

Debugger information (DBG) records and traceback information (TBT) records are processed only if the debugger was requested and traceback information was not excluded by the /NOTRACE qualifier in the LINK command. Otherwise, these records are ignored. The records contain stack and store object language commands (TIR records), but they are stored in the debugger symbol table (DST) instead of in an image section. (The linker expands its memory region to accommodate the DST, unless the /NOTRACEBACK qualifier was specified in the LINK command.)

When the linker processes end-of-module (EOM) records, it checks that its internal stack has been collapsed to its initial state. When this processing is complete, the linker has written the binary contents of all image sections to image section buffers in its own address space.

The linker writes the contents of its buffers in the following order:

1. All image sections to the image file.
2. The debugger symbol table to the image file, unless /NOTRACEBACK was specified in the LINK command.
3. The remaining sections of the map to the map file, if requested in the LINK command. (These sections include all requested sections except the Object Module Synopsis, which it already wrote, and the Link Run Statistics, which it cannot write until the linking operation finishes.)
4. The global symbol table to the image file, and also to another separate file, if requested in the LINK command.
5. The image header to the image file.
6. The link statistics to the map file, if requested in the LINK command.