HP OpenVMS Systems Documentation

Porting Applications from HP OpenVMS Alpha to HP OpenVMS Industry Standard 64 for Integrity Servers

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:

$ link/SHARE public/PUBLISH,implementation/EXPORT=public
$ link/SHARE plib/LIBRARY/PUBLISH/INCLUDE=public/EXPORT=public

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.

5.3.3.5 New Alignments for the PSECT_ATTRIBUTE Option

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).

5.3.3.6 New GROUP_SECTIONS and SECTION_DETAILS keywords for the /FULL Qualifier

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 Synopsis.

5.3.4 Mixed-Case Arguments in Linker Options, Revisited

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:

CASE_SENSITIVE=YES.

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:

CASE_SENSITIVE=NO

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.

5.4 Debugging Capabilities on OpenVMS I64 Systems

Several debuggers are provided on OpenVMS that allow for a wide range of debugging capabilities:

• OpenVMS Debugger (referred to simply as debugger)
• Delta (not available on OpenVMS I64)
• XDelta
• Source code debugger (SCD) (not available on OpenVMS I64)

The OpenVMS Debugger and XDelta debugger are available on OpenVMS 8.2. The following table shows the capabilities of these debuggers:

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.

5.4.1 OpenVMS Debugger

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.

5.4.1.1 Architecture Support

OpenVMS I64 debugger supports the following hardware registers:

• General registers R0 through R127
• Floating registers F0 through F127
• Branch registers B0 through B7
• A 64-bit predicate value named PRED, representing predicate registers P0 through P63
• Application registers: AR16 (RSC), AR17 (BSP), AR18 (BSPSTORE), AR19 (RNAT), AR25 (CSD), AR26 (SSD), AR32 (CCV), AR36 (UNAT), AR64 (PFS), AR65 (LC), AR66 (EC)
• A program counter named PC, synthesized from the hardware IP register and the ri field of the PSR register
• Miscellaneous registers: CFM (current frame marker), UM (user mask), PSP (previous stack pointer), and IIPA (previously executed bundle address)

OpenVMS I64 Debugger supports programs written in the following languages:

• BLISS
• C
• C++ (limited)
• COBOL (limited)
• Macro-32
• Fortran
• Intel® Assembler (IAS)

Some issues exist when debugging supported languages on OpenVMS I64. For information about these issues and suggested workarounds, refer to the HP OpenVMS Version 8.2 Release Notes.

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.

5.4.1.3 Functional Areas and Commands

The following functional areas and commands are available:

• Screen mode: source display, instruction display, output display
• Instruction decoding
• Breakpoints
• Watchpoints (non-static)
• Step (all forms)
• DEBUG/KEEP command (kept debugger configuration)
• RUN/DEBUG command (normal debugger configuration)
• Multithreaded programs
• CALL command
• Symbolic debugging of code in shareable images
• Symbolization of all possible static data locations
• Values in floating-point registers are displayed as IEEE T-floating values
• Examines and deposits of floating-point variables
• EXAMINE/ASCII command

The following capabilities have not yet been ported to OpenVMS I64:

• DECwindows graphical user interface
• Heap analyzer
• Screen mode register view
• SHOW STACK command

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.

5.4.2.1 XDelta Capabilities on OpenVMS I64

New capabilities have been added for OpenVMS I64 systems:

• XDelta supports the following Itanium registers:
  • General registers: R0 through R127
  • Floating registers: FP0 through FP127
  • Application registers: AR0 through AR127
  • Branch registers: BR0 through BR7
  • Control registers: CR0 through CR63
  • Miscellaneous registers: PC, PS, and CFM
  • Software implementation of Alpha registers
• ;D dump memory command
• ;T display interrupt stack command

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.

5.4.2.2 Differences Between XDelta on OpenVMS I64 and OpenVMS Alpha Systems

This section describes the differences in XDelta behavior on I64 and Alpha systems.

Interrupting a Running System

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.

Improved Symbolization

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.

5.5 OpenVMS I64 Librarian Utility

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.

5.5.1 Considerations When Using the I64 Librarian

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:

• /OBJECT --- Uses OpenVMS ELF object libraries (default).
• /SHARE --- Uses OpenVMS ELF shareable image libraries.
• /CREATE --- Creates an OpenVMS ELF library of an object or shareable image type, depending whether /OBJECT or /SHARE qualifier is specified.

The default library type created is an object library, if no OBJECT and SHARE qualifiers are specified.

5.5.2 Changes to the LBR$ Routines

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.
LBR$C_TYP_ELFSHSTB (10) --- Represents an ELF shareable image 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.
LBR$C_TYP_SHSTB (5) --- Represents a VAX shareable image library.
LBR$C_TYP_EOBJ (7) --- Represents an Alpha object library.
LBR$C_TYP_ESHSTB (8) --- Represents an Alpha shareable image library.

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 definitive definition.

5.5.3.1 New ELF Type for Weak Symbols

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):

• Type STB_WEAK represents the UNIX-style weak symbol (formerly, the OpenVMS-style weak symbol definition for ABI Version 1 ELF format)
• Type STB_VMS_WEAK represents the OpenVMS-style of weak symbol definition

The Librarian supports both the ELF ABI versions 1 and 2 of the object and image file formats within the same library.

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.

5.5.3.3 New Group-Section Symbols

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.

5.5.3.4 Current Library Limitation with Regard to Weak and Group Symbols

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.

This chapter provides an overview of porting considerations related to the primary compilers that are available for OpenVMS I64. Table 6-1 maps the versions of Alpha compilers that were used to port to the I64 versions.

Most of the OpenVMS I64 compilers share the following characteristics:

• They generate 32-bit code by default; you must use a compiler option to build a 64-bit program.
• The default is for IEEE floating-point data types instead of VAX floating-point data types.
  The "OpenVMS Floating-Point Arithmetic on the Intel® Itanium® Architecture" white paper describes how I64 deals with floating-point issues. See the Related Documents section in the Preface for the web location of this white paper and other OpenVMS-to-Itanium architecture resources.

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.

6.1 Ada

Ada 95 is available on I64 in OpenVMS Version 8.2. Ada 83 is not supported on I64.

6.2 BASIC

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 Alpha.

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: