HP OpenVMS Systems Documentation

HP OpenVMS Version 8.2 New Features and Documentation Overview

Specifying a base address in the CLUSTER option is permitted only on VAX and Alpha systems. On Alpha systems, only main images are allowed to contain based clusters. VAX systems are more flexible; even shareable images are allowed to contain based clusters. On I64 systems, specifying a base address in a CLUSTER option is illegal for all images.

7.1.1.3 Handling of Initialized Overlaid Program Sections on OpenVMS I64 Systems

On Alpha and VAX systems, initializations can be done to portions of an overlaid program section. Subsequent initializations to the same portions overwrite initializations from previous modules. The last initialization performed on any byte is used as the final one of that byte for the image being linked.

On I64 systems, the ELF object language currently does not implement the feature of the Alpha and VAX object language which allows the initialization of portions of the program sections. When an initialization is made, the entire section is initialized. Subsequent initializations of this section may be performed only if the nonzero portions match in value. This is called a compatible initialization.

For example, the following condition produces different results on OpenVMS I64 systems than on Alpha systems:

Two program sections, each declaring two longwords, are overlaid. The first program section initializes the first longword and the second program section initializes the second longword with a nonzero value.

On Alpha systems, the linker is able to produce an image section with the first and second longword initialized. The VAX and Alpha object languages give the linker the section size and the Text Information Relocation (TIR) commands to initialize each longword.

On I64 systems, the linker gets sections that contain initialization data from the compilers. The linker does not perform or know about the initializations, because there are no TIR commands in ELF. The linker then produces an image segment using the last processed program section for initialization. That is, in the image either the first or second longword has a nonzero value, depending on the order in which they were linked. Although an image is produced, the linker regards this as an error and issues a message.

On I64 systems, the linker reads all the applicable initializations and checks for compatibility. Any two initializations are compatible if they are identical in the nonzero values. If they are not compatible, the linker issues the following error message:

%ILINK-E-INVOVRINI, incompatible multiple initializations for
 overlaid section
        section:  <section name>
        module:   <module name for first overlaid section>
        file:  <file name for first overlaid section>
        module:  <module name for second overlaid section>
        file:  <file name for second overlaid section>

In this error message, the linker lists the first module, which contributes a nonzero initialization, and the first module with an incompatible initialization. Note that this is not a full list of all incompatible initializations; it is just the first one the linker encounters.

In the Program Section Synopsis of the linker map, each module with a nonzero initialization is flagged as "Initializing Contribution". Use this information to identify and resolve all the incompatible initializations.

The following example shows the additional information in the map file (see Example 7-1):

$ cre one.c
int common_data[]={0,0,47,11};
[Exit]
$ cc /extern=common one
$
$ cre two.c
int common_data[]={0,0,47,11};
[Exit]
$ cc /extern=common two
$
$ cre three.c
int common_data[]={0,0,0,0,0,0,0,0};
[Exit]
$ cc /extern=common three
$
$ link/map one,two,three
.
.
.

Example 7-1 shows the program section synopsis of the linker map for the above example. Note that the Align and Attributes fields normally continue after the Length field but were modified to fit on the page.

                                    +--------------------------+
                                    ! Program Section Synopsis !
                                    +--------------------------+


Psect Name      Module/Image     Base     End           Length
----------      ------------     ----     ---           ------
COMMON_DATA                    00010000 0001001F 00000020 (      32.)
                ONE            00010000 0001000F 00000010 (      16.)
                TWO            00010000 0001000F 00000010 (      16.)
                THREE          00010000 0001001F 00000020 (      32.)


Align                 Attributes
-----                ------------
OCTA  4 OVR,REL,GBL,NOSHR,NOEXE,  WRT,NOVEC,  MOD
OCTA  4 Initializing Contribution
OCTA  4 Initializing Contribution
OCTA  4

Another example shows an incompatible initialization and the resulting linker message:

$ cre four.c
int common_data[]={0,0,47,11,0,0,17,4};
[Exit]
$ cc /extern=common four
$
$link one,two,three,four
%ILINK-E-INVOVRINI, incompatible multiple initializations for
 overlaid section
        section: COMMON_DATA
        module: ONE
        file: DISK$USER:[JOE]ONE.OBJ;1
        module: FOUR
        file: DISK$USER:[JOE]FOUR.OBJ;1

The examples were compiled with the extern common model. For VMS the default extern model is the relaxed refdef model. In that model, there is only one explicit initialization that is allowed. That is, even identical initializations result in a linker warning message, the multiply defined message. Here is an example, which uses the same source files as above:

$ cc one
$ cc two
$ cc three
$
$ link one, two, three
%ILINK-W-MULDEF, symbol COMMON_DATA multiply defined
        module: TWO
        file: DISK$USER:[JOE]TWO.OBJ;2
%ILINK-W-MULDEF, symbol COMMON_DATA multiply defined
        module: THREE
        file: DISK$USER:[JOE]THREE.OBJ;2

For an additional incompatible initialization the linker shows both messages, the INVOVRINI error and the MULDEF warning. And, for such a module, the INVOVRINI, precedes the MULDEF message. In this case, the user has to fix the MULDEF warning to get rid of the INVOVRINI error.

$ cc four
$
$ link one,two,three,four
%ILINK-W-MULDEF, symbol COMMON_DATA multiply defined
        module: TWO
        file: DISK$USER:[JOE]TWO.OBJ;2
%ILINK-W-MULDEF, symbol COMMON_DATA multiply defined
        module: THREE
        file: DISK$USER:[JOE]THREE.OBJ;2
%ILINK-E-INVOVRINI, incompatible multiple initializations for
 overlaid section
        section: COMMON_DATA
        module: ONE
        file: DISK$USER:[JOE]ONE.OBJ;2
        module: FOUR
        file: DISK$USER:[JOE]FOUR.OBJ;2
%ILINK-W-MULDEF, symbol COMMON_DATA multiply defined
        module: FOUR
        file: DISK$USER:[JOE]FOUR.OBJ;2

The I64 linker behaves differently when ELF common symbols (or, on Alpha, relaxed refdef symbols) are linked selectively against an image that contains a definition for the same symbol. On Alpha, the linker incorrectly takes the definition from the relaxed refdef symbol in your module. The I64 linker takes the definition from the shareable image.

For example, a shareable image is linked from the following module (my_int.c):

 #include ints
 uint64 my_int ;
 $cc/extern=relaxed my_int.c
 $link/map/full/cross/share my_int,sys$input/opt
 symbol_vector=(my_int=data)

Next, another C module (x.c) is selectively linked against my_$int.exe. Note that the object is compiled with the relaxed extern model. The result is a conditional reference/definition generated for my_int.

 #include ints
 uint64 my_int;
 main()
 {
 my_int = 1;
 return;
 }

 $cc/extern=relaxed x.c
 $link/map/full/cross sys$input/opt
 cluster=myclu,,,x.obj
 my_int.exe/share/select

The Alpha linker incorrectly defines my_int from the module's conditional definition of my_int. The I64 linker correctly retrieves the definition from my_int.exe.

The Alpha linker is not being changed to preserve those cases that rely upon this behavior. The I64 linker performs the selection operation correctly.

7.1.1.5 Flags Set When /TRACEBACK, /DEBUG, and /DSF are Used

When the /TRACEBACK, /DEBUG and /DSF linker debug qualifiers are specified, the following flags are set for the image activator. These flags are set in the dynamic segment under the tag value DT_VMS_LNKFLAGS. Note that the meanings of the /TRACEBACK, /DEBUG and /DSF qualifiers have not changed from Alpha, but the meanings and the names of the flags have changed.

The flags will be set according to the following table:

Notes

• The value of SYS$IMGSTA is no longer included in the image's transfer array; only a flag that indicates it is to be called. The image activator knows the value of SYS$IMGSTA.
• These flags do not appear in a DSF file. DSF files are not activated by the image activator (they have no dynamic segment and therefore no DT_VMS_LNKFLAGS field).
• The Linker no longer supports /DEBUG=filename on I64 systems. Link alternative debuggers as a separate image and then define LIB$DEBUG to point to that image. SYS$IMGSTA always calls whatever is pointed to by LIB$DEBUG.
• When /DSF is specified, along with /TRACEBACK or /DEBUG, the VMS_LF_TBK_IN_IMG (traceback in image) flag will be set. This is a change in behavior from the behavior on Alpha, where traceback records were not included in the image when /TRACEBACK/DSF or /DEBUG/DSF was specified. Note that debugger records do not get copied to an image whenever /DEBUG/DSF is specified. Here, /DEBUG only causes the IMGSTA bit to be set in the image.

The following table indicates where global symbol definitions are written during a link operation for an image that does not use the SYMBOL_TABLE or SYMBOL_VECTOR option.

The following sections describe aspects of linking images on I64 systems that are unique to the platform. Topics include:

• Understanding linkage messages ( Section 7.1.2.1)
• Considerations for Images Compiled with Reduced Floating Point Model ( Section 7.1.2.2)
• Considerations for Linking with ELF Groups and UNIX-style weak Symbols ( Section 7.1.2.3)
• Use of the new /BASE_ADDRESS Qualifier ( Section 7.1.3.1)
• Use of the new /SEGMENT_ATTRIBUTE Qualifier ( Section 7.1.3.2)
• Use of the new /FP_MODE Qualifier ( Section 7.1.3.3)
• Use of the new /EXPORT_SYMBOL_VECTOR and /PUBLISH_GLOBAL_SYMBOLS qualifiers ( Section 7.1.3.4)
• Use of the new GROUP_SECTIONS and SECTION_DETAILS keywords for the /FULL Qualifier ( Section 7.1.3.5)
• New Alignments for the PSECT_ATTRIBUTE Option ( Section 7.1.4.1)

Some HP compilers produce call linkage information that verifies the linkage of a caller or a called routine to determine consistent use of the general registers across modules. Linkage information is supplied for only the general registers 0 through 31. Conflicts arise when the linkage information indicates a problem.

The following example shows a warning message that displays when the linker detects a linkage conflict:

%ILINK-W-LNKGERR, linkage to routine X is not compatible with
 linkage of caller
        calling module: MOD_SRC
                file: DISK:[DIR]SOURCE.OBJ;1
        target  module: MOD_TARG
                file: DISK:[DIR]TARGET.OBJ;1
        source type of JSB to target type of CALL
        register AI not provided (needed at target)
        register GP not provided (needed at target)
        IA64 register R19 (Alpha R21) -- call=PRESERVE, target=VOLATILE

Following the display of the source and target information are messages that indicate the nature of the conflict or conflicts that caused the warning message to be displayed. If a caller does not provide argument information in the argument information register (AI) when the target routine requires the AI, the linker will generate a message similar to the one in the above example.

In addition to missing required information, inconsistent or incompatible use of the general registers can also cause a linkage conflict. The linkage information contains register policies for the general registers, which are as follows:

• Volatile: A register with this policy may not be used to pass information between procedures, either as input or output.
• Scratch: A register with this policy may be modified by the called procedure.
• Output: A register with this policy may be used to pass information back to the calling procedure.
• Preserve: A register with this policy must have its contents saved and then restored, if it is to be used by the target routine.

The register policies of a standard linkage call are as follows:

A standard procedure call uses the CALL mechanism and provides the Global Pointer (GP) value and the AI register fill with the argument information.

The following table indicates compatible policies between the caller's register policies (row heading) and the target routine's register policies (column heading):

In the sample message:

IA64 register R19 (Alpha R21) - call-PRESERVE, target=VOLATILE

Intel® Itanium® register R19 has a caller register policy of "Preserve" but a target routine register policy of "Volatile". Based on the above table, R19 is not compatible between the caller and the target routines.

Additionally, the calling mechanism between the routines is not compatible. This occurs because the caller is performing a JumptoSuBroutine (JSB) to the target routine when the target routine is expecting a CALL mechanism to be used.

Certain Intel® Itanium® registers must be defined to have specific policies. If these registers do not contain the correct policies, the linker will issue a warning indicating that either the target linkage is invalid (1) or a message of the caller is invalid (2):

(1) %ILINK-W-INVLNKG, invalid target linkage for symbol INV_LNKG

(2) %ILINK-W-INVRLNKG, invalid call linkage for symbol INV_LNKG

The following table lists the Intel® Itanium® general registers that have specific policies:

Explanation of Potential Conflicts that Result in Linkage Messages

Some conflicts arise when performing cross language calls (for example, IMACRO to BLISS), where the calling standards for OpenVMS differ between Alpha and I64 systems. There are fewer registers preserved by default with the Intel® Itanium® version of the calling standard. Because of this, there may be assumptions about registers that are saved at the target routine and registers that are not saved.

Linkage statement mismatches also cause the linker to display warning messages. For example, if a calling routine is expecting register R12-R15 (Alpha register numbers) to be preserved but the target does not preserve them, the linker will list registers R20, R21, R30, and R31 as having a linkage problem but will include the Alpha register numbers in parentheses.

Additionally, a problem can exist when registers that are not properly declared for the function they are serving, for example, declaring registers to return values as NOPRESERVE rather than OUTPUT.

To correct these potential conflicts, examine the declaration and definition linkages for all cases the linker indicates and correct these problems to ensure a clean link operation. Because the linker considers these conflicts warnings, the completion code status of the image will not be set to SUCCESS. For a shareable image, this means that images linked against a shareable image with linkage issues will, themselves, receive a completion status other than SUCCESS.