|
HP OpenVMS Systems Documentation |
|
HP OpenVMS Version 8.2 New Features and Documentation Overview
7.1.2.2 Considerations for Images Compiled with Reduced Floating Point Model
On OpenVMS I64 systems, images using a reduced floating point model
will run more quickly during interrupts because only a reduced number
of floating point registers need to be saved and restored. Note that
some integer arithmetic is done using floating point registers. The
resulting image can be run in a reduced floating point mode only if all
object modules that contribute to the image have been compiled with the
reduced floating point model. The Object and Image Synopsis section of
the linker map file indicates if the modules have the reduced floating
point model.
The Intel C++ compiler introduced the use of Executable and Linking Format (ELF) Groups (that is, COMDATs) and UNIX-style Weak symbols that the Linker (and the Librarian) must correctly handle. ELF groups in object modules can be seen as tentative code and data contributions with definitions for variables and procedures. The C++ compiler makes use of this feature for C++ templates. The compiler simply generates code and data for a template: a group. In such an environment multiple object modules will have multiple identical contributions with the same code and data. For the image, the linker selects one contribution from each group. So the result of linking multiple object modules with multiple identical groups is one instance of code and data per group in the image. An ELF group has a name, also called group signature. Groups are as seen identical if they have the same name. Symbols can belong to a group; they are called group symbols. As usual, group symbols can be used for definitions or references. The UNIX-style weak definition differs from the VMS-style weak definition (Alpha and VAX): there can be multiple UNIX-style weak definitions. UNIX-style weak references are similar to the Alpha and VAX style references: when they are unresolved, they do not cause an error or warning. UNIX-style Weak symbols from an ELF Group take the first occurrence of the specific group as the defining instance. All subsequent definitions of these UNIX-style Weak symbols from other occurrences of that group are then seen as references to the first instance. UNIX-style Weak symbols are, by design, tentative. If present, and if there is no occurrence of a strong definition elsewhere among the other modules or images of the link, the first encountered UNIX-style Weak version of the symbol is regarded as the defining instance. A strong definition overwrites a UNIX weak definition, which becomes a reference. The other UNIX weak symbols of the same group become references. This does not create a problem: all symbols, including strong definitions, are generated by the compiler or defined in the run time environment. Understanding this mechanism helps to understand the linker map. UNIX weak symbols defined in a group can be referenced by non-weak symbols outside a group. The cross reference list in the map has a UNIX weak tag in front of UNIX weak definitions and references. Typically, the UNIX weak tagged definitions are the result of selecting a group from an object module. The UNIX weak tagged references are usually a result of a secondary occurrence of the same group. An untagged definition with a UNIX weak tagged reference is usually a result of a strong definition overwriting a group symbol from an object module. The tagging in the cross reference table enables the user to see which module was selected as owning the defining instance of the symbol. The cross reference does not list the group signatures (that is, their names). The ANALYZE utility can be used to find all symbols belonging to a group. Additionally, you can ask the linker for a list of all groups and their defining modules and files by using the /MAP/FULL=GROUP_SECTIONS qualifiers. User-written templates can be linked as a shareable image. Symbols that are exported (made universal) by a shareable image are always strong definitions. With the precedence of strong definitions over UNIX weak ones, the code and data of the shareable image is the linker selected contribution. For OpenVMS I64, the grouping of symbols is preserved in the shareable image as well. In this case, where all the symbols are strong definitions, a group from a shareable image always takes precedence over all identical groups in object modules. There is one difference between groups in a shareable image and groups in an object module. If the same group is seen in another shareable image, the linker warns of a second occurrence of the group. In this case, the resulting image may not behave as expected. Code and data from the first occurrence of the group will be used by all object modules within the defining shareable image, but code and data from the other occurrences will be used within the other defining shareable images. When linking a shareable image, make sure that all symbols of all groups making up the template implementation are exported. Otherwise, redundant code and data may appear in the resulting image, or - as mentioned above - wrong code or data may be used.
The original OpenVMS-style weak symbols continue to be processed in the
same manner as before.
Some new linker qualifiers have been added to support linking on
OpenVMS I64 systems. This section describes these features.
A new qualifier, /BASE_ADDRESS, is provided on I64 systems. The base address is the starting address that you want the linker to assign to an executable image. The purpose of this qualifier is to assign a virtual address for images which are not activated by the OpenVMS image activator, such as images used in the boot process. The OpenVMS image activator is free to ignore any linker-assigned starting address. This qualifier is primarily used by system developers.
The /BASE_ADDRESS qualifier does not replace the
CLUSTER=,[base-address] option, which is illegal on OpenVMS
I64. See Section 7.1.1.2.
The OpenVMS I64 Linker provides a new /SEGMENT_ATTRIBUTE qualifier that accepts two keywords: SHORT_DATA=WRITE and DYNAMIC_SEGMENT=P0 or P1. The /SEGMENT_ATTRIBUTE qualifier uses the following syntax:
By default, the linker puts the dynamic segment, which contains information for the image activator, into P2 space. But by specifying DYNAMIC=P0, it forces the linker to put the dynamic segment into P0 space. As such, the DYNAMIC_SEGMENT keyword is rarely needed.
The SHORT_DATA=WRITE keyword allows you to combine read-write and
read/write short data sections into a single segment, reclaiming up to
65,535 bytes of unused read-only space. When setting SHORT_DATA to
WRITE, your program may accidentally write to formerly read-only data.
Therefore this qualifier is only recommended for users whose short data
segment has reached the limit of 4 MB.
The OpenVMS I64 Linker determines the program's initial floating point mode using the floating point mode provided by the module that provides the main transfer address. Use the /FP_MODE qualifier to set an initial floating point mode only if the module that provides the main transfer address does not provide an initial floating point mode. The /FP_MODE qualifier will not override an initial floating point mode provided by the main transfer module. The OpenVMS I64 Linker accepts the following keywords to set the floating point mode:
The OpenVMS I64 Linker accepts the following IEEE behavior keywords:
The OpenVMS I64 Linker also accepts a floating point mode behavior
literal. For more information about the initial floating point mode,
see the HP OpenVMS Calling Standard.
The /EXPORT_SYMBOL_VECTOR and /PUBLISH_GLOBAL_SYMBOLS qualifiers were added to the linker to aid users who are creating shareable images but do not know which symbols to export through the SYMBOL_VECTOR option. (Users may have been porting an application from UNIX and were unfamiliar with the application, such that they did not know which symbols to export. Another possible scenario is that because they were coding in C++, they were not able to know what the mangled names looked like.) The new /PUBLISH_GLOBAL_SYMBOLS qualifier marks an object module so that all its global symbols can be exported in a symbol vector option. The new /EXPORT_SYMBOL_VECTOR qualifier writes a symbol vector option for each global symbol in modules marked with /PUBLISH_SYMBOL_VECTOR to the output file. When /EXPORT_SYMBOL_VECTOR is present, only the option file is written; no image file is generated. The generated option file needs to be completed with GSMATCH information by the developer for use in a future link. Both qualifiers are only accepted if the /SHAREABLE qualifier is present. /EXPORT_SYMBOL_VECTOR is a command line only qualifier. /PUBLISH_GLOBAL_SYMBOLS can be used in option files as well. The linker will issue a warning if there is an /EXPORT_SYMBOL_VECTOR qualifier but no /PUBLISH_GLOBAL_SYMBOLS qualifier is seen.
/EXPORT_SYMBOL_VECTOR=[file-spec]
/EXPORT_SYMBOL_VECTOR instructs the I64 linker to create an options file with a symbol vector option filled in as directed by the /PUBLISH_GLOBAL_SYMBOLS qualifier, plus a template GSMATCH option. Using the /EXPORT_SYMBOL_VECTOR qualifier prohibits image production. If /EXPORT_SYMBOL_VECTOR is given, symbol_vector options as input are not allowed. At least one /PUBLISH_GLOBAL_SYMBOLS must be on the command line or in an option. The qualifier also specifies the character string you want the linker to use as the name of the options file that the link operation produces. If you do not specify a file type in the character string, the linker assigns the .OPT file type by default. If you do not specify a file name with the /EXPORT_SYMBOL_VECTOR qualifier, the linker creates an options file with the file name of the first input file. If you append the /EXPORT_SYMBOL_VECTOR qualifier to an input file specification, the linker creates an options file with the file name of the file to which the qualifier is appended. After filling in the GSMATCH template option, the generated options file should be used in another link operation to create the shareable image file.
/PUBLISH_GLOBAL_SYMBOLS
The /PUBLISH_GLOBAL_SYMBOLS qualifier instructs the I64 linker to mark an object module or object module library for exporting all its global symbols to a symbol vector options file as requested by the /EXPORT_SYMBOL_VECTOR qualifier. The qualifier can only be used with the /SHAREABLE and /EXPORT_SYMBOL_VECTOR qualifiers. The qualifier is compatible with the /INCLUDE and /SELECTIVE_SEARCH qualifiers. The qualifier can be used on the command line and in a linker option. If the qualifier is applied to an object file, all global symbols from all modules in that file are candidates to be exported as a symbol vector option. If the qualifier is applied to an object file in combination with the /SELECTIVE_SEARCH qualifier, only referenced global symbols from all modules in that file are candidates to be exported as a symbol vector option. If the qualifier is applied to an object library, all global symbols from all modules of the object library, which were implicitly included in the image, are candidates to be exported as a symbol vector option. If the qualifier is applied to an object library in combination with the /INCLUDE qualifier, all global symbols from the modules in the include list of the object library are candidates to be exported as a symbol vector option. If the qualifier is applied to an object library built with the /SELECTIVE_SEARCH qualifier, only referenced global symbols from all modules of the object library, which were included in the image, are candidates to be exported as a symbol vector option. (See the HP OpenVMS Command Definition, Librarian, and Message Utilities Manual for how to insert modules in a library that can be selectively searched.) If the global symbol is a tentative definition (that is, from the C relaxed refdef extern model) in several modules it is published if one of the modules is marked with /PUBLISH. Similarly, for UNIX weak symbols, any of the modules can make this a candidate to be exported as a symbol vector option. However, for both symbol types, if symbols are overwritten by strong definitions, the presence of /PUBLISH from the defining module determines if the symbols are candidates to be exported as a symbol vector option. Examples:
All the global symbols from the modules in PUBLIC.OBJ are exported as a symbol vector option to the file PUBLIC.OPT.
Only the global symbols from the modules in IMPLEMENTATION.OBJ, which are referenced from modules in API_TABLE.OBJ are exported as a symbol vector option to the file PUBLIC.OPT.
All the global symbols from the all modules of the library PLIB.OLB, which are included in the shareable image are exported as a symbol vector option to the file PLIB.OPT.
All the global symbols from the module public of the library PLIB.OLB are exported as a symbol vector option to the file PLIB.OPT.
All the global symbols from all the modules of the library PLIB.OLB, which are referenced from all the modules in api_table, exported as a symbol vector option to the file PUBLIC.OPT. And similar examples with /PUBLISH used in an options file, are in the following:
All the global symbols from the modules in PUBLIC.OBJ are exported as a
symbol vector option to TT: that is printed to the terminal.
The OpenVMS I64 Linker takes two keywords to the /FULL qualifier that direct the linker to create a full image map. The format of the /FULL qualifier is:
The OpenVMS I64 Linker accepts the following keywords to tailor the map (the default is /FULL=SECTION_DETAILS):
The first keyword, GROUP_SECTIONS, prints all of the groups that were used in the map. Today the only compiler that takes advantage of groups is C++. Using this keyword with other languages has no effect.
When /FULL=NOSECTION_DETAILS is specified the OpenVMS I64 Linker
suppresses zero length contributions in the Program Section Synopsis of
the map. When the qualifier /FULL is used, it defaults to
/FULL=SECTION_DETAILS, and a full linker map on VAX, Alpha, and I64
systems lists all the module contributions in the Program Section
Synopsis.
Some new linker options have been added to support linking on OpenVMS
I64 systems. This section describes these features.
The PSECT_ATTRIBUTE option now accepts integers 5, 6, 7, and 8 for the
alignment attribute. The integers represent the byte alignment
indicated as a power of 2. (For example, 2 ** 6 represents a 64-byte
alignment.) The keyword HEXA (for hexadecimal word) was added for 2 **
5 (that is, a 32-byte or 16-word alignment).
The following sections describe new ways to use existing linker qualifiers and options on I64 systems. Topics include:
7.1.5.1 Mixed-Case Arguments in Linker Options on I64 SystemsOn OpenVMS I64 systems, names issued by compilers may be mixed-case names. If you need to operate on mixed-case names in the options file (for example you have a library include statement and the module names are mixed-case) the linker already has an option to process the names in mixed-case, rather than using its default behavior (uppercasing all names). That option is the CASE_SENSITIVE option:
When the CASE_SENSITIVE option is set to YES, all characters to the right of the left-most equal sign (such as option arguments) have their case preserved. In other words, these characters are taken as-is without modification. This includes file names, module names, symbol names and keywords. To restore the linker's default behavior of upcasing the entire option line, specify the CASE_SENSITIVE option with the NO keyword, as follows:
Note that the NO keyword must appear in uppercase or it will not be recognized by the linker. For example, the following module contains mixed-case names that you want to preserve by setting the linker to case-sensitive mode.
When processed by the linker, the text appears as follows:
The case of all names to the right of the first equal sign in each option remains the same.
To maintain VAX and Alpha behavior, HP recommends that you switch to
case sensitivity only when needed.
The following conventions describe the various names that apply to an image:
On Alpha systems, the image name specified with NAME= is used to identify self-references in the shareable image list. Self-references are calls from within the image to itself, by means of an alias name in the symbol vector.
On I64 systems, there is no entry in the shareable image list for the
current image. Self-references are referred to with a special index
value into the shareable image list (-1 in the DT_VMS_FIXUP_NEEDED
field) that results in a a set of DT_NEEDED entries.
Do not specify a smaller section alignment with the PSECT_ATTRIBUTE than the alignment that the compiler gave to the section. If you specify a smaller alignment for a program section than any compiler-assigned alignment from all contributions to this section, the linker now issues a warning. For example:
For the VAX and Alpha systems, the linker inappropriately aligns the program section on the boundary that you specified ("byte", in the above code example), and places all the contributions to that program section (from other modules you might have linked with "hi", in the above example) on boundaries that were not specified by the compiler. The linker would not have issued an error message. The linker always aligns sections on a boundary that is greater than or equal to what was specified by the compiler.
The PSECT_ATTRIBUTE option aligns the section on the specified boundary
when it is equal to or greater than that which the compiler specified.
It does not align each individual contribution to the section; rather,
the total section. The PSECT_ATTRIBUTE option follows the compiler's
alignment specification when it aligns each individual contribution.
When the RMS_RELATED_CONTEXT linker option is on (the default is RMS_RELATED_CONTEXT=YES) and a nonexistent file is specified in a list of files for the LINK command, the linker's call to LIB$FIND_FILE takes a long time to complete and the linker may appear to hang. Depending on the number of files being linked and the use of logical names in their specification, the linker may take hours to finish because LIB$FIND_FILE locates every combination of the missing file's prefix before displaying a "file not found" message. Note that you cannot terminate the linker process with Ctrl/Y after the linker has called LIB$FIND_FILE. To quicly find out what the missing file specification is, specify /OPTION in the LINK command. When you press Return, the linker waits for you to enter information into an options file. When you are finished, press Ctrl/Z. To avoid the problems with LIB$FIND_FILE, include the following items in the options file:
For example, consider the following LINK command:
If you want to specify this command with RMS_RELATED_CONTEXT=NO, you would specify /OPTION and then enter full file specifications for the files to be linked, as follows:
The following example shows how the linker appears to hang when file DOES_NOT_EXIST.OBJ is included in the list and the RMS_RELATED_CONTEXT option is not specified (and therefore defaults to YES).
|