HP OpenVMS Systems Documentation

Content starts here

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

Previous Contents Index

4.8.8 Code that Relies on the OpenVMS Alpha Calling Standard

If your application relies explicitly on characteristics of the OpenVMS Alpha calling standard, you likely have to change it. The OpenVMS I64 calling standard is based on the Intel calling standard with some OpenVMS modifications. Significant differences introduced in the OpenVMS I64 calling standard include the following:

  • No frame pointer (FP)
  • Multiple stacks
  • Only four registers preserved across calls
  • Register numbers you are familiar with have changed

For more information, see Chapter 2.

4.8.9 Privileged Code

This section describes categories of privileged code that require examination, and may require modifications. Use of SYS$LKWSET and SYS$LKWSET_64

If your application uses SYS$LKWSET or SYS$LKWSET_64 to lock itself into memory, and your application does not run on VAX systems, consider replacing these calls with calls to the new (as of OpenVMS Version 8.2) LIB$LOCK_IMAGE RTL routine. Similarly, replace the SYS$ULWSET and SYS$ULWSET_64 calls with calls to the new LIB$UNLOCK_IMAGE RTL routine.

Programs that enter kernel mode and increase IPL to higher than 2 must lock program code and data in the working set. Locking code and data is necessary to avoid crashing the system with a PGFIPLHI bugcheck.

On VAX systems, typically only the code and data explicitly referenced by the program need to be locked. On Alpha, the code, data and linkage data referenced by the program need to be locked. On I64 systems, code, data, short data, and linker generated code need to be locked. To make porting easier and because the addresses of short data and linker generated data cannot be easily found within an image, changes have been made to the SYS$LKWSET and SYS$LKWSET_64 system services on Alpha and I64.

As of OpenVMS Version 8.2, the SYS$LKWSET and SYS$LKWSET_64 system services test the first address passed in. If this address is within an image, these services attempt to lock the entire image in the working set. If a successful status code is returned, the program can increase IPL to higher than 2 and without crashing the system with a PGFIPLHI bugcheck.

A counter is maintained within the internal OpenVMS image structures that counts the number of times the image has been successfully locked in the working set. The counter is incremented when locked and decremented when unlocked. When the counter becomes zero, the entire image is unlocked from the working set.

If your privileged program runs on Alpha and I64 and not VAX, you can remove all the code that finds the code, data and linkage data and locks these areas in the working set. You can replace this code with calls to LIB$LOCK_IMAGE and LIB$UNLOCK_IMAGE (available in OpenVMS Version 8.2). These routines are simpler to program correctly and make your code easier to understand and maintain.

If the program's image is too large to be locked in the working set, the status SS$_LKWSETFUL is returned. If you encounter this status, you can increase the user's working set quota. Otherwise, you can split the image into two parts, one that contains the user mode code and another sharable image that contains the kernel mode code. At the entry to a kernel mode routine, the routine should call LIB$LOCK_IMAGE to lock the entire image in the working set. Before exiting the kernel mode routine, the routine should call LIB$UNLOCK_IMAGE. Use of SYS$LCKPAG and SYS$LCKPAG_64

If your application uses SYS$LCKPAG or SYS$LCKAPG_64 to lock code in memory, examine your use of this service. On I64, this service will not lock the entire image in the working set.

It is likely that you intend to lock the image in the working set so your code can elevate IPL and execute without incurring a page fault. Refer to Section See also the HP OpenVMS RTL Library (LIB$) Manual for information about the LIB$LOCK_IMAGE and LIB$UNLOCK_IMAGE routines. Terminal Drivers

The interface for terminal class drivers on OpenVMS I64 is a call-based interface. This is a significant difference from the JSB-based interface on OpenVMS Alpha that uses registers to pass arguments.

The interface for OpenVMS I64 terminal class drivers is documented in the OpenVMS Terminal Driver Port Class Interface for Itanium. This document is available at the following location:

http://www.hp.com/products1/evolution/alpha_retaintrust/openvms/resources Protected Image Sections

Protected image sections usually occur in shareable images which implement "User Written System Services."

These image sections are protected by software and hardware mechanisms to assure that an unprivileged application cannot compromise the integrity of these sections. Changes in hardware pages protection from VAX and Alpha to I64 have added some subtle restrictions which may require changes in the protected images.

As on VAX and Alpha, data sections that are writeable in privileged modes (kernel or exec) may be read by unprivileged (user) mode. The hardware protection for such pages does not allow execute access from any mode. Protected image sections which are linked as both writeable and executable are protected to allow inner mode read, write, and execute; no user mode access is allowed. As neither user mode access to inner mode writeable data, nor code being in writeable sections, is a common practice, it is felt that few applications are likely to require both in a single section.

While there were exceptions on VAX and Alpha, on I64, all writeable protected image sections on I64 are protected against user mode write. Protected images which intend to allow user write to protected image sections must use $SETPRT/$SETPRT_64 to alter the page protection.

Chapter 5
OpenVMS I64 Development Environment

This chapter contains information about the OpenVMS I64 development environment, including:

  • Native I64 compilers
  • Other development tools
  • Linker
  • Debugger
  • Librarian utility

5.1 Native I64 Compilers

For OpenVMS I64, native I64 compilers are available for the following languages:

  • BLISS (available on the Freeware CD)
  • C++
  • COBOL V2.8
  • Fortran V8.0 (Fortran 90)
  • HP C V6.5
  • HP Pascal
  • Java
  • VAX Macro-32

No support is provided to compile native Alpha Macro-64 assembler code to run on OpenVMS I64.

The I64 compilers provide command-line qualifiers for using VAX floating-point data types. For more information about these compilers, except for the VAX Macro-32 compiler, see Chapter 6.

5.1.1 VAX MACRO--32 Compiler for OpenVMS I64

For new program development for OpenVMS I64, HP recommends the use of high-level languages. HP provides the VAX Macro--32 compiler for OpenVMS I64 to convert existing VAX MACRO code into machine code that runs on OpenVMS I64 systems.

Most VAX MACRO code can be compiled without any changes. The exceptions are:

  • Programs that call routines that do not comply to the OpenVMS I64 calling standard.
  • Programs that use the JSB instruction to call routines written in a language other than Macro-32.

For more information about porting VAX MACRO programs to OpenVMS I64 systems, refer to the HP OpenVMS MACRO Compiler Porting and User's Guide.

5.2 Other Development Tools

Several other tools in addition to the compilers are available to develop, debug, and deploy native I64 applications. These tools are summarized in Table 5-1.

Table 5-1 OpenVMS Development Tools
Tool Description
OpenVMS Linker The OpenVMS Linker accepts I64 object files to produce an I64 image. For more information about the OpenVMS Linker, see Section 5.3.
OpenVMS Debugger The OpenVMS Debugger running on OpenVMS I64 has the same command interface as the current OpenVMS Alpha debugger. The graphical interface on OpenVMS Alpha systems will be available in a later release. For more information about the OpenVMS Debugger on OpenVMS I64, see Section 5.4.
XDelta Debugger The XDelta Debugger is an address location debugger that is used for debugging programs that run in privileged processor mode or at an elevated interrupt priority level. The XDelta Debugger is available for this release but the related Delta Debugger is not yet available.
OpenVMS Librarian utility The OpenVMS Librarian utility creates I64 libraries.
OpenVMS Message utility The OpenVMS Message utility allows you to supplement the OpenVMS system messages with your own messages.
ANALYZE/IMAGE The Analyze/Image utility can analyze I64 images.
ANALYZE/OBJECT The Analyze/Object utility can analyze I64 objects.
DECset DECset, a comprehensive set of development tools, includes the Language Sensitive Editor (LSE), the Digital Test Manager (DTM), Code Management System (CMS), and Module Management System (MMS). The two remaining DECset tools, Performance and Coverage Analyzer (PCA) and the Source Code Analyzer (SCA), will be available in a future release.
Command Definition utility The Command Definition utility (CDU) enables application developers to create commands with a syntax similar to DCL commands.
System Dump Analyzer (SDA) SDA has been extended to display information specific to OpenVMS I64 systems.
Crash Log Utility Extractor (CLUE) CLUE is a tool for recording a history of crash dumps and key parameters for each crash dump, and for extracting and summarizing key information.

5.2.1 Translating Alpha Code

The HP OpenVMS Migration Software for Alpha to Integrity Servers is a binary translator for translating Alpha user code images to run on OpenVMS I64 systems. This tool is useful in cases where the source code is no longer available, or when the compiler is not available on I64, or when a third-party product has not been ported to OpenVMS I64. A third-party product's permission is required from the owner of the software.

The HP OpenVMS Migration Software for Alpha to Integrity Servers offers functionality similar to that of DECmigrate, a binary translator that was used to port OpenVMS VAX images to run on OpenVMS Alpha systems.

For more information, see Section

5.3 Linking Modules

The purpose of the linker is to create images (files that contain binary code and data). The linker ported to OpenVMS I64 is different from the linker on OpenVMS VAX and Alpha systems because it accepts OpenVMS I64 object files and produces OpenVMS I64 images. As on OpenVMS VAX and Alpha systems, the primary type of image created is an executable image. This image can be activated at the DCL command line by issuing the RUN command.

The OpenVMS I64 Linker also creates shareable images. A shareable image is a collection of procedures and data that are exported via the symbol_vector option, that can be called by executable images or other shareable images. Shareable images are included in an input file via a link operation that creates an executable or shareable image.

When linking modules, the primary type of input file to the OpenVMS I64 Linker is the object file. Object files are produced by language processors such as compilers or assemblers. Because the object files produced by these compilers are unique to the Intel Itanium architecture, some aspects of linking modules on OpenVMS I64 are different. In general, the OpenVMS I64 linker interface as well as functional capabilities (for example, symbol resolution, virtual memory allocation, and image initialization) are similar to those on OpenVMS VAX and Alpha systems. This section provides an overview of the differences as well as considerations you should review before linking programs on OpenVMS I64 systems. These include:

  • Differences when linking on I64 systems as compared with linking on VAX and Alpha systems ( Section 5.3.1)
  • Expanded linker map file information for I64 ( Section 5.3.2)
  • New linker qualifiers and options ( Section 5.3.3)
  • Mixed-Case Arguments in Linker Options, Revisited ( Section 5.3.4)

For details of these features and considerations, refer to the HP OpenVMS Version 8.2 New Features and Documentation Overview.

5.3.1 Differences When Linking on OpenVMS I64 Systems

Although linking on OpenVMS I64 systems is similar to linking on OpenVMS Alpha systems, some differences exist. The following qualifiers or options are ignored by the OpenVMS I64 linker:

  • The per_page keyword in /DEMAND_ZERO=PER_PAGE (the per_page keyword will be supported, though with a slightly different meaning, in a future release)

The following qualifiers and options are not allowed by the OpenVMS I64 Linker:

  • The file name keyword in /DEBUG=file_spec
  • The base address keyword must be null in CLUSTER=cluster_name,base_address ...
  • BASE=

The following are new qualifiers supported by the OpenVMS I64 Linker:

  • /FP_MODE
  • The GROUP_SECTIONS and SECTIONS_DETAILS keywords for the /FULL command

Some of these qualifiers and options are described in the following sections. For more details on these qualifiers and options see the HP OpenVMS Version 8.2 New Features and Documentation Overview. No Based Clusters

Specifying a base address in a CLUSTER option is permitted on VAX and Alpha. On VAX even shareable images are allowed to contain based clusters, whereas on Alpha only main images are allowed to consist of such clusters. For I64 specifying a base address in a CLUSTER option is illegal for all images. Handling of Initialized Overlaid Program Sections on OpenVMS I64

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 (Executable and Linkable Format) object language does not implement the feature of the Alpha and VAX object language which allows the initialization of portions of sections. When an initialization is made, the entire section is initialized. Subsequent initializations of this section may be performed only if the non-zero portions match in value.

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

Two program sections (simply termed 'sections' in ELF), 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 non-zero 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 the section.

On I64 systems, the linker gets pre-initialized sections which contain initialization data from the compilers. The linker does not perform or know about the initializations since there are no TIR commands in ELF. The linker then produces a segment using the last processed section for initialization. That is, in the image either the first or second longword has a non-zero value, depending on the order in which the modules containing the sections were linked. On I64 systems, the linker reads the sections to be overlaid and checks for compatibility. Any two overlaid sections are compatible if they are identical in the non-zero values. If they are not compatible, the linker issues the following error:

%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 the previous message, the linker lists the first module that contributes a non-zero 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 non-zero initialization is flagged as "Initializing Contribution." Use this information to identify and resolve all the incompatible initializations. For further examples and more detail on the handling of initialized overlayed sections, see the HP OpenVMS Version 8.2 New Features and Documentation Overview. Behavior Difference When Linking ELF Common Symbols

The I64 linker behaves differently when ELF common symbols (also known as relaxed ref/def 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 ref/def symbol in your module. The I64 linker takes the definition from the shareable image.

5.3.2 Expanded Map File Information

Information in the linker map file has been expanded for OpenVMS I64 systems:

  • On Alpha systems, the map section that was titled Object Module Synopsis has been renamed on I64 systems to Object and Image Synopsis, and contains expanded object and image information.
  • On Alpha systems, the map section titled Image Section Synopsis has been divided into two sections for I64 systems: Cluster Synopsis and Image Segment Synopsis. The information has been moved to the appropriate section.
  • In the Program Section Synopsis, the PIC and NOPIC attributes, invalid on I64 systems, have been removed.
  • In the Symbol Cross Reference section, the designation for an external symbol has changed. The prefix or suffix used on Alpha was RX, meaning relocateable and external. However, the linker does not know whether an external symbol is relocatable or not. As a result, on I64 systems the prefix or suffix has been changed to X (external).
  • In the Symbols By Value section, Keys for Special Characters have been changed or expanded. For example, UNIX weak symbols, (very likely only used by C++), designated by the UxWk key, are a new addition to OpenVMS I64.

For an example linker map illustrating this new information, refer to the HP OpenVMS Version 8.2 New Features and Documentation Overview.

5.3.3 New Linker Qualifiers and Options for OpenVMS I64

Some new linker options and qualifiers have been added to support linking on OpenVMS I64 systems. This section describes these features. New /BASE_ADDRESS Qualifier

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

For more information on this qualifier, see the HP OpenVMS Version 8.2 New Features and Documentation Overview. New /SEGMENT_ATTRIBUTE Qualifier

The OpenVMS I64 Linker provides a new /SEGMENT_ATTRIBUTE which accepts two keywords: SHORT_DATA=WRITE and DYNAMIC_SEGMENT = P0 or P1. The DYNAMIC_SEGMENT keyword is rarely needed. For more information see the HP OpenVMS Version 8.2 New Features and Documentation Overview.

The SHORT_DATA=WRITE keyword allows you to combine read-only 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.

For more details on this qualifier, see the HP OpenVMS Version 8.2 New Features and Documentation Overview. New /FP_MODE Qualifier

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:

  • D_FLOAT, G_FLOAT---Sets VAX floating point modes.
  • IEEE_FLOAT[=ieee_behavior]---Sets the IEEE floating point mode to the default or a specific behavior.

The OpenVMS I64 Linker accepts the following IEEE behavior keywords:

  • FAST
  • DENORM_RESULTS (default)

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.

Previous Next Contents Index