|
||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||
|
 |
 |
HP OpenVMS systems documentation |
|
| Previous | Contents | Index |
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:
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.
4.8.9.1 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.
4.8.9.2 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 4.8.9.1. See also the HP OpenVMS RTL Library (LIB$) Manual for information about
the LIB$LOCK_IMAGE and LIB$UNLOCK_IMAGE routines.
4.8.9.3 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 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.
This chapter contains information about the OpenVMS I64 development environment, including:
For OpenVMS I64, native I64 compilers are available for the following languages:
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:
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.
| 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. |
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 4.1.2.1.
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:
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 following qualifiers and options are not allowed by the OpenVMS I64 Linker:
The following are new qualifiers supported by the OpenVMS I64 Linker:
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.
5.3.1.1 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.
5.3.1.2 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.
5.3.1.3 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:
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.
5.3.3.1 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 5.3.1.1.
For more information on this qualifier, see the HP OpenVMS Version 8.2 New Features and Documentation Overview.
5.3.3.2 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.
5.3.3.3 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:
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.
| Previous | Next | Contents | Index |