HP OpenVMS Systems Documentation
Porting Applications from HP OpenVMS Alpha to HP OpenVMS Industry Standard 64 for Integrity Servers
126.96.36.199 New /EXPORT_SYMBOL_VECTOR and /PUBLISH_GLOBAL_SYMBOLS Qualifiers
The EXPORT_SYMBOL_VECTOR and PUBLISH_GLOBAL_SYMBOLS qualifiers were added to the linker to aid customers who are creating shareable images but did not know which symbols to export through the SYMBOL_VECTOR option. This could be because they were porting an application from UNIX and were not familiar enough with the application to know which symbols to export, or because they were coding in C++, and were not able to know what the mangled names looked like.
The OpenVMS I64 Linker provides a new /PUBLISH_GLOBAL_SYMBOLS qualifier to mark an object module, so that all its global symbols can be exported in a symbol vector option. Additionally, the OpenVMS I64 Linker provides a new /EXPORT_SYMBOL_VECTOR qualifier to export a symbol vector option and to name the output file.
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 warn, if there is an /EXPORT_SYMBOL_VECTOR qualifier but no /PUBLISH_GLOBAL_SYMBOLS qualifier was seen.
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.
The /PUBLISH_GLOBAL_SYMBOLS qualifier is a positional qualifier and can be used with object files and libraries. It is compatible with the /INCLUDE and /SELECTIVE qualifiers, for example:
The /EXPORT_SYMBOL_VECTOR qualifier is a positional qualifier, which accepts an optional output file specification. If there is no file name specified the linker will use the name of the last input file and construct a file name, default file type is ".OPT".
For more detailed information on this qualifier, see the HP OpenVMS Version 8.2 New Features and Documentation Overview.
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 OpenVMS I64 Linker takes two keywords to the /FULL qualifier. 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
On 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 as shown below:
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.
To maintain VAX and Alpha behavior it is recommended to switch to case sensitivity only when needed.
For more information and examples, refer to the HP OpenVMS Version 8.2 New Features and Documentation Overview.
Several debuggers are provided on OpenVMS that allow for a wide range of debugging capabilities:
The OpenVMS Debugger and XDelta debugger are available on OpenVMS 8.2. The following table shows the capabilities of these debuggers:
+IPLs 0, 1, and 2 only
The following sections describe the capabilities of the OpenVMS
Debugger and the XDelta debugger running on OpenVMS I64 systems.
Further information about resolved problems, limitations, and known
problems of the OpenVMS Debugger can be found in the HP OpenVMS Version 8.2 Release Notes.
The debugger provided on OpenVMS I64 is different from the OpenVMS VAX
and Alpha debugger. Although the OpenVMS I64 debugger shares a similar
command interface and debugging functionality, some differences do
exist. The following sections describe the capabilities of the OpenVMS
I64 Debugger and assume a familiarity with the debugger on OpenVMS VAX
and Alpha systems.
OpenVMS I64 debugger supports the following hardware registers:
188.8.131.52 Language Support
OpenVMS I64 Debugger supports programs written in the following languages:
Support for C++ and COBOL in this release is limited. Generally, Debugger support for C++ is limited to programming constructs that are common to C, although support for basic C++ features such as references, classes, and class members is available.
Do not use the SHOW SYMBOL/ADDRESS and SHOW SYMBOL/TYPE commands for C++ data declarations. Specific examples of these and other problems are described in the HP OpenVMS Version 8.2 Release Notes.
Macro-32 is a compiled language on OpenVMS I64. Because the Itanium
architecture has different hardware register usage than either Alpha or
VAX, the IMACRO compiler must transform source code references to Alpha
and VAX registers into a compatible register reference on Itanium. For
complete information on register mapping used by Macro-32, refer to the
HP OpenVMS Version 8.2 Release Notes.
The following functional areas and commands are available:
184.108.40.206 Functionality Not Yet Ported
The following capabilities have not yet been ported to OpenVMS I64:
5.4.2 XDelta Debugger
In general, the XDelta Debugger for OpenVMS I64 systems behaves the
same as XDelta on OpenVMS Alpha systems, with some restrictions. This
section describes new capabilities added for OpenVMS and differences
between XDelta on OpenVMS I64 and OpenVMS Alpha systems.
New capabilities have been added for OpenVMS I64 systems:
For descriptions of these registers and capabilities in this release,
refer to the HP OpenVMS Version 8.2 New Features and Documentation Overview. This document also describes the ;D and ;T
commands, along with some restrictions.
This section describes the differences in XDelta behavior on I64 and Alpha systems.
To interrupt a running system on I64, press Ctrl/P at the system console. Note that XDelta must have been previously loaded. When you press Ctrl/P,the system halts at the current PC and at the current IPL. There is no delay in waiting for the IPL to drop lower than 14 as on Alpha systems.
The X-registers are used by programmers to hold frequently used values,
such as base addresses of images and modules. When displaying
breakpoints and other address values, XDelta now prints these values
relative to the nearest X-register value. Previously, only certain
values were checked for proximity to X-register values.
The Librarian utility on OpenVMS I64 provides the same features
provided by Librarian on OpenVMS Alpha, with some changes and
restrictions. This section describes what is unique about the I64
Librarian. For information about restrictions or other temporary
conditions, refer to the HP OpenVMS Version 8.2 Release Notes.
You can use the DCL command LIBRARY (or Librarian LBR routines) to create libraries such as an I64 (ELF) object library, I64 (ELF) shareable image library, macro library, help library, and text library. You can maintain the modules in a library or display information about a library and its modules. The I64 Librarian cannot create or process Alpha and VAX objects and shareable images. Rather, the architecture for the Librarian is Intel Itanium.
There is no architecture switch for I64 libraries. The Librarian works with OpenVMS ELF object and image libraries when used with the following qualifiers:
The default library type created is an object library, if no OBJECT and
SHARE qualifiers are specified.
Two new library types for the LBR$OPEN routine have been added on I64 systems:
LBR$C_TYP_ELFOBJ (9) --- Represents an ELF object library.
In addition, the following library types for the LBR$OPEN routine are not supported in the I64 Librarian. You cannot use the library types to create or open OpenVMS Alpha or VAX object and shareable image libraries:
LBR$C_TYP_OBJ (1) --- Represents a VAX object library.
5.5.3 I64 Library Format Handles UNIX-Style Weak Symbols
Due to the requirements of the Intel C++ compiler, the I64 library format has been expanded to accommodate new UNIX-style weak symbols. Multiple modules matching key names of new UNIX-style weak symbols can now exist in the same library. The Librarian ignores the OpenVMS-style weak symbol definitions as it has in the past.
UNIX-style weak symbol definitions behave in the same manner as weak
transfer addresses on OpenVMS; that is, their definitions are
tentative. If a definition of a stronger binding type is not seen
during a link operation, the tentative definition is designated as the
A new Executable and Linkable Format (ELF) type was generated to distinguish between the two types of weak symbol definitions. For modules with ABI versions equal to 2 (the most common version used by compilers):
The Librarian supports both the ELF ABI versions 1 and 2 of the object and image file formats within the same library.
220.127.116.11 Version 6.0 Library Index Format
HP recommends using the new Version 6.0 libraries. Older (Version 3.0)
libraries can be opened by the Library Services but cannot be not
modified. They can be converted to Version 4.0 libraries, with some
restrictions. For more information, refer to the HP OpenVMS Version 8.2 New Features and Documentation Overview.
Symbols may be relative to sections contained in an ELF entity called a
group. These groups, and the symbols associated with
them, behave in a similar fashion as the new UNIX-style weak symbol
definitions; that is, they are tentative definitions. The librarian now
allows multiple symbol definitions in the library's symbol name index.
Library symbol entries are associated with the module within which they were defined. On OpenVMS I64, more than one module can define a UNIX-style weak or Group symbol. As such, the I64 Librarian must keep an ordered list of defining modules. This list allows a previous association to be restored should the higher precedence association be removed (you can find more information about precedence ordering rules in the HP OpenVMS Version 8.2 Release Notes.)
Because of current limitations described in the HP OpenVMS Version 8.2 Release Notes, HP suggests that you only perform insert operations into the library only for modules that contain UNIX-style weak definitions. If you remove or replace modules in the library, you need to rebuild the library to make sure that the association of UNIX-style weak definitions is correct.
|Compiler||On OpenVMS Alpha||On OpenVMS I64||For more information|
|BASIC||V1.6||V1.6||See Section 6.2.|
|BLISS||V1.11-004||V1.12-067||See Section 6.3.|
|COBOL||V2.8||V2.8||See Section 6.4.|
|Fortran 77||---||Not available 1||See Section 6.5.2.|
|Fortran 90||V7.5||V8.0||See Section 6.5.|
|GNAT Pro Ada 95||Third party||---||See Section 6.1.|
|HP Ada 83||V3.5A||Not available 1||---|
|HP C||V6.5||V7.1||See Section 6.6.|
|Java||1.4.2||1.4.2-1||See Section 6.8.|
|Macro-32||V4.1-18||T1.0-77||See Section 6.9.|
|Macro-64||V1.2||Not available 1||---|
Most of the OpenVMS I64 compilers share the following characteristics:
HP recommends that customers first compile their applications on
OpenVMS Alpha with the versions of the compilers that are being ported
to OpenVMS I64 in order to shake out any problems that might result
from these newer compilers. (Some newer versions of compilers apply a
stricter interpretation of existing compiler standards or enforce
newer, stricter standards.) Once an application has compiled, linked,
and run without error on the new compiler on an OpenVMS Alpha system,
it can be ported to OpenVMS I64.
Ada 95 is available on I64 in OpenVMS Version 8.2. Ada 83 is not
supported on I64.
The same BASIC is supported on both Alpha and I64. See the BASIC Release Notes for additional information on using BASIC on OpenVMS I64.
The BASIC compiler on OpenVMS Alpha defaults to /REAL_SIZE=SINGLE (VAX F-float), and on OpenVMS I64 it defaults to /REAL_SIZE=SFLOAT.
The BASIC compiler does not support the /IEEE_MODE qualifier. The
compiler and RTL set up the run-time environment on I64 to be similar
in terms of exception handling and rounding to what is provided on
6.3 BLISS Compiler
This section describes the differences between the OpenVMS Alpha and OpenVMS I64 BLISS compilers.
BLISS-32EN and BLISS-64EN are native compilers running on and generating code for OpenVMS for Alpha systems.
BLISS-32IN and BLISS-64IN are native compilers running on and generating code for OpenVMS I64 systems.
The BLISS-32xx compilers perform operations 32 bits wide (that is, BLISS values are longwords). The default width is 32 bits. In this chapter, they are collectively referred to as "the 32-bit compilers."
The BLISS-64xx compilers perform operations 64 bits wide (that is, BLISS values are quadwords). The default width is 64 bits. In this chapter, they are collectively referred to as "the 64-bit compilers".
The compilers are invoked using the following commands:
|Alpha||BLISS-32EN||BLISS/A32 or BLISS|
|I64||BLISS-32IN||BLISS/I32 or BLISS|