|
||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||
|
 |
 |
HP OpenVMS systems documentation |
|
| Previous | Contents | Index |
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:
The OpenVMS Debugger and XDelta debugger are available on OpenVMS 8.2. The following table shows the capabilities of these debuggers:
| Category | OpenVMS Debugger | XDelta |
|---|---|---|
| Debugs operating systems | no | yes |
| Debugs applications | yes | no |
| Symbolic | yes | no |
| IPL greater than 0 | no | yes |
| Process content | yes | no |
| User mode | yes | no+ |
| Supervisor mode | no | no+ |
| Exec mode | no | yes |
| Kernel mode | no | yes |
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:
OpenVMS I64 Debugger supports programs written in the following languages:
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:
The following capabilities have not yet been ported to OpenVMS I64:
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:
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.
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.
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:
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):
The Librarian supports both the ELF ABI versions 1 and 2 of the object and image file formats within the same library.
The new library format (Version 6.0) applies only to ELF object and shareable image libraries. Other libraries remain at the version 3.0 format. Applications that reference the library via the currently defined library services interface should not encounter any change in behavior. |
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.
| 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. |
| HP C++ | V6.5 | 7.1 | --- |
| HP Pascal | V5.9 | V5.9 | --- |
| 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.
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:
| Platform | Compiler | Command |
|---|---|---|
| Alpha | BLISS-32EN | BLISS/A32 or BLISS |
| Alpha | BLISS-64EN | BLISS/A64 |
| I64 | BLISS-32IN | BLISS/I32 or BLISS |
| I64 | BLISS-64IN | BLISS/I64 |
| Previous | Next | Contents | Index |