V8.3

The following release notes pertain to the I64 Linker utility.

For Alpha Linker release notes, see Section 5.25.

5.26.1 Linker Writes Incorrect Interimage Debug Fixups into Debug Symbol File

V8.3

In some situations, the linker creates interimage fixups for the OpenVMS debugger. The interimage debug fixup is a result of compiler-generated debug relocations, which the linker cannot resolve. That is, the debugger requires these fixups to determine a value from a shareable image at run-time. Compilers might differ on how often they require the linker to create inter-image fixups for the debugger. The C compiler rarely uses inter-image debug fixups, but the C++ compiler often uses them. When linking such images with /DEBUG, the linker writes the debug information followed by the interimage debug fixups. With /NODSF (the default) the information is written correctly into the image file, but with /DSF the information is sometimes written incorrectly into the DSF file.

For example, the DEBUG informationals and the DEBUG error in the following sample occur because the linker has written the DSF file incorrectly:

$ RUN/DEBUG MINIREF %DEBUG-I-INFODWARF, error reading Dwarf info: Section 0a extends outside file %DEBUG-I-INFODWARF, error reading Dwarf info: Section 0c extends outside file %DEBUG-I-INFODWARF, error reading Dwarf info: SHT_VMS_FIXUP section 10 size 17eb e0 not multiple of 18 %DEBUG-I-INFODWARF, error reading Dwarf info: SHT_VMS_FIXUP section 12 size 17ec 30 not multiple of 18 OpenVMS I64 Debug64 Version V8.3-003 %DEBUG-F-ACCVIO, access violation, reason mask=00, virtual address=000000000014A 000, PC=000000007BD73100, PS=0000001B %DEBUG-I-INITIAL, Language: C, Module: MINIREF DBG>

The image file is not affected; it can be executed with the RUN command without any problem:

$ RUN MINIREF

This error will be corrected in the next release of the I64 Linker:

5.26.2 OpenVMS I64 Object Module and Image File Information Currently Unavailable

V8.3

Information about the OpenVMS I64 extension to ELF (Executable and Linkable Format; the object module and image file format on I64) is not available at this time. It will be provided in a future release.

For information about the Alpha or VAX object language format, see the respective appendixes in the OpenVMS Alpha/VAX Version 7.3 OpenVMS Linker Utility Manual, available from the documentation bookshelf at the following URL:

http://h71000.www7.hp.com/doc/os732_index.html

5.26.3 /SELECTIVE_SEARCH Might Incorrectly Ignore Transfer Address

V8.3

If you have an I64 object module containing a transfer address and you include the module in the link operation with the /SELECTIVE_SEARCH qualifier, the linker will not find its transfer address.

In the following example, the object module (MAIN.OBJ) contains a transfer address but /SELECTIVE_SEARCH ignores it:

$ LINK MAIN/SELECTIVE_SEARCH %ILINK-W-USRTFR, image USER:[JOE]MAIN.EXE;1 has no user transfer address

This condition happens only when I64 object modules, meant to provide the program's transfer address, are included in the link operation with the SELECTIVE_SEARCH attribute. The SELECTIVE_SEARCH attribute is given to an object module when you specify /SELECTIVE_SEARCH qualifier to the object module in the LINK command. For example,

$ LINK MAIN/SELECTIVE_SEARCH

A LIBRARY command,

$ LIBRARY/INSERT LIB.OLB MAIN.OBJ/SELECTIVE_SEARCH

when that module from the library is used to resolve references in a link operation, either implicitly,

$ LINK/EXECUTABLE=MAIN SUBROUTINES.OBJ, LIB.OLB/LIBRARY

or explicitly:

$ LINK/EXECUTABLE=MAIN SUBROUTINES.OBJ, LIB.OLB/INCLUDE=MAIN

This problem manifests itself in one of two ways:

• The linker displays where a warning message as in the preceding example. This condition occurs if no other object module in the link operation provides a transfer address, weak or otherwise.
• The linker does not display a message. Such a condition occurs if other object modules in the link operation provide a transfer address, weak or otherwise. If the linker fails to properly identify the transfer address from the selectively searched object module, it selects one from the other object modules. That transfer address unintentionally becomes the main entry point for the image, although this was not intended. Even though the map file does indicate the incorrect transfer module and transfer address the linker has assigned, the problem might not become evident until you actually run your application.

V8.3

Be sure to read the HP OpenVMS Version 8.3 New Features and Documentation Overview for a complete description of the differences between the OpenVMS I64 Linker and the OpenVMS Alpha Linker. The HP OpenVMS Version 8.3 New Features and Documentation Overview also contains a description of features that are new with the OpenVMS I64 Linker.

5.26.5 LINK_ORDER Section Header Flag Not Supported

V8.2

The Linker does not support the LINK_ORDER ELF section header flag. However, unwind sections, which have this flag set, are placed in the correct order.

This flag indicates that the section, if combined with other sections in the image file, be combined in the same order as the order of the sections to which they refer are combined. Unwind sections are handled as special cases and appear in the correct order.

The following figure illustrates this concept.

V8.2

DCX data-reduced ELF object libraries are not stored in contiguous space in the library. As a result, the module cannot be directly mapped into process P2 space because data expansion must first occur. The LBR$MAP_MODULE library service expands and copies the module into process P2 space. This action causes the resulting pages in P2 space to be counted against process quota.

The LBR$UNMAP_MODULE library service recovers those pages but the pages remain in a heap storage free list and continue to be counted against process quota. For this reason, HP strongly recommends that DCX data-reduced ELF object libraries first be expanded before performing Linker operations. This is a permanent condition.

5.26.7 Error in Handling Initialized Overlaid Program Sections Fixed

V8.3

In previous versions of the I64 linker, initialized overlaid program sections with zeros are incorrectly seen as compatible initializations. In OpenVMS Version 8.2 and Version 8.2­1, the I64 Linker accepts sections initialized with zeros to be compatible with sections containing nonzero initial values. Under this condition, the order of modules in a link operation can result in different initial values in the image.

This problem is fixed in Version 8.3.

5.26.8 Removal of Linker Qualifiers /EXPORT_SYMBOL_VECTOR and /PUBLISH_GLOBAL_SYMBOLS

V8.3

Creating a shareable image by simply exporting all global symbols does not work. Previous I64 Linker versions provide the /EXPORT_SYMBOL_VECTOR and /PUBLISH_ GLOBAL_ SYMBOLS qualifiers to assist in creating symbol vector options for all global symbols on a per-module basis. However, using these qualifiers exports the same universal symbol from different images. Because you cannot exclude exporting the same C++ template from different images, this creates problems.

Both qualifiers are removed from the Version 8.3.

This problem will be fixed for the I64 Linker in a future release of OpenVMS for I64.

5.26.9 Support for Longer Symbol Names in Options

V8.3

For options, the linker internal line buffer is increased to hold 2048 characters. This allows specifying options with symbol names of the maximum supported length of 1024 characters.

5.26.10 Better Use of Memory for Linker-Created Code Stubs

V8.3

The I64 linker generates code stubs, which are visible when stepping through the code with the OpenVMS Debugger. Code can be inserted for calls and can have different sizes. However, the earlier linker added the code as fixed-size code sections using the maximum necessary code size.

The Version 8.3 linker writes the code stubs using the actual size. This eliminates unused space between the stubs and might also release unused memory.

5.26.11 Compiler Support for Demangled Symbol Names

V8.3

To make symbol names unique, name mangling is used for some programming languages. Starting with Version 8.3, the linker tries to display the demangled names, also known as source code names. These names are used in linker messages and, on request, in a translation table for mangled global symbols that appears in the linker map (see HP OpenVMS Version 8.3 New Features and Documentation Overview). This feature depends on compiler support for name demangling.

5.26.12 Maximum Number of Sections

V8.3

For more than 65280 sections, the ELF format uses an extended numbering scheme, which is currently not implemented in the I64 linker. That limits the number of sections a single input object module or shareable image can have. Because the linker usually creates the shareable images with sections, this limit applies for creating shareable images as well. Here, ELF sections are used for exporting C++ templates or shared sections. That is the maximum number of such interfaces in a shareable image must be fewer than 65280.

5.26.13 Incorrect Creation Date of Shareable Images in the Map File

V8.2

On OpenVMS I64 platforms, shareable images might show an incorrect creation date in the linker map. The incorrect date is shown is usually 3686. This condition occurs when the linker processes the shareable image as an input file and then extracts the date field, which is shown in the map. The image itself has the correct date that you can see from ANALYZE/IMAGE output.

This problem will be fixed in a future release of the I64 Linker.

5.27 LTDRIVER: CANCEL SELECTIVE Restriction

Permanent Restriction

In releases prior to OpenVMS Version 6.1, LTDRIVER did not set the "extended DDT" bit; therefore, the POSIX function CANCEL SELECTIVE did not work with LTDRIVER. This problem has been corrected, but a restriction remains.

Although this fix allows $QIO reads and writes to be selectively canceled, any $QIO done to the port driver (that is, with the IO$_TTY_PORT function modifier --- such as a LAT connect $QIO) cannot be canceled with CANCEL SELECTIVE.

5.28 Mail Utility: Threads Restriction for Callable Mail

V7.1

OpenVMS callable mail routines are not thread-safe. Refer to the Guide to the POSIX Threads Library for more information about calling non-thread-safe routines within a threaded application.

Because callable mail context information is maintained on a per-process (rather than a per-thread) basis, multiple threads performing context-based processing must be synchronized so that only one mail context of a given type is active at once. Otherwise, one thread could corrupt another thread's mail operations.

On OpenVMS Alpha systems, there is an additional restriction when kernel threads is enabled in a multithreaded environment. In this environment, callable mail should be used only in the initial thread.

5.29 OpenVMS Debugger

The following release notes describe conditions specific to the OpenVMS Debugger on OpenVMS I64 and Alpha systems.

For release notes about the DELTA and XDELTA debuggers, see Section 5.13.

5.29.1 STEP/SEMANTIC_EVENT Information Missing in Debugger Command-Line Help

V8.3 Information for the /SEMANTIC_EVENT qualifier does not display properly in Debugger command-line help under the STEP command. Information for this qualifier can be found in the command reference section of the HP OpenVMS Debugger Manual, under STEP command.

5.29.2 Problems and Conditions Corrected in this Release (I64 Only)

V8.3

The following list describes conditions that are corrected in this release:

General Condition: Arrays whose elements are on unaligned boundaries formerly did not displayed properly. This occurred when a programming language construct was used to force unnatural data alignment (for example, #pragma nomember_align in C or the PACKED keyword in Pascal). This condition is fixed.

COBOL Language Condition: Previously, data declared with EDIT picture clauses were only partially supported. This condition is fixed.

Fortran Language Condition: Previously, a deposit of a value into a data item declared as REAL*16 resulted in a zero being stored rather than the actual value. This condition is fixed.

Pascal Language Condition: Previously, arrays declared with dynamic bounds (for example, "array [1..n]") were not always handled correctly. This condition is fixed.

V8.2

The following general conditions have been identified, along with user workarounds:

Condition: Arrays whose elements are on unaligned boundaries are not displayed properly. This occurs when a programming language construct is used to force unnatural data alignment (for example, #pragma nomember_align in C or the PACKED keyword in Pascal).

Workaround: None.

Condition: When examining an array with scalar (integer) subscripts, the debugger prints the array index values in the currently defined radix, rather than in the decimal radix.

Workaround: Issue the SET RADIX DECIMAL command.

Condition: OpenVMS Debugger on I64 systems displays general, floating-point and predicate registers as if the register rename base (CFM.rrb) and rotating size (CFM.sor) are both zero. In other words, when rotating registers are in use, the effects of the rotation are ignored. This will be corrected in a future release. See Section 5.10 for additional details.

Workaround: Examine the CFM register and manually adjust the EXAMINE command to account for the nonzero CFM.rrb and CFM.sor fields.

5.29.4 BASIC Language Issues (I64 Only)

V8.2

Condition: When examining a range of a multi-dimensional array, the debugger does not correctly symbolize the element's location. That is, the array row and column values are incorrect.

Workaround: None.

5.29.5 C++ Language Issues (I64 Only)

V8.2

Condition: The SHOW CALLS command sometimes displays C++ mangled names, rather than unmangled names.

Workaround: None.

5.29.6 COBOL Language Issues (I64 Only)

V8.2

Condition: Data declared with EDIT picture clauses are only partially supported. Examining the item (using the EXAMINE command) displays the raw data without scaling or other adjustments. Changing the item by depositing an integer or decimal constant (using the DEPOSIT command) may result in an error.

Workaround: Manually adjust the displayed value by the appropriate scale factor. If you need to change the value, execute the DEPOSIT command using another variable or a quoted string as the source.

5.29.7 Fortran Language Issues (I64 Only)

V8.2

Condition: A deposit of a value into a data item declared as REAL*16 always results in a zero being stored rather than the actual value.

Workaround: None.

5.29.8 Pascal Language Issues (I64 Only)

V8.2

Condition: Arrays declared with dynamic bounds (for example, "array [1..n]") are not always handled correctly. When examining the array, the debugger will sometimes display INVARRDSC or IVALOUTBNDS errors, and SHOW SYMBOL/TYPE may incorrectly display the array bounds.

Workaround: None.

5.29.9 SET SCOPE Command: Behavior Change

V8.2

The behavior of the SET SCOPE command has changed in this release. SET SCOPE now changes the debugger's language setting to the language of the specified scope. Previously, SET SCOPE did not affect the language setting. You can disable this capability by issuing the SET LANGUAGE NODYNAMIC command.

5.29.10 SHOW IMAGE Command Change

V8.2

The SHOW IMAGE command now displays a summary of the address space occupied by the images in your process. To see the full image section information, use SHOW IMAGE/FULL, or specify an image name (for example, SHOW IMAGE FOO).

5.29.11 Client/Server Interface: Previous Versions Not Supported (Alpha Only)

V7.3

The Debugger for OpenVMS Alpha Version 7.3 and later does not support previous versions of the client/server interface. You must install the client/server interface found in the kit on the distribution media, as identified in the following table.

CPU	Operating System	Client Kit
Intel	Microsoft Windows 95, 98, NT, Me, 2000, XP	[DEBUG_CLIENTS011.KIT] DEBUGX86011.EXE
Alpha	Microsoft Windows NT	[DEBUG_CLIENTS011.KIT] DEBUGALPHA011.EXE

These client kits are self-extracting .EXE files.

Once the appropriate executable file has been transferred to the PC, you can run the file to install the debug client on the PC. The InstallShield installation procedure guides you through the installation.

5.30 OpenVMS System Dump Analyzer (SDA)

The following notes pertain to the System Dump Analyzer (SDA).

5.30.1 CLUE Commands Not Ported to OpenVMS I64

V8.2

The following CLUE commands have not yet been ported to OpenVMS I64 and will return a message to that effect:

CLUE CALL
CLUE ERRLOG
CLUE FRU
CLUE REGISTER

V8.2

The PL/I libraries (native and translated) are not included in OpenVMS I64 as they are in OpenVMS Alpha. The core PL/I images that are not available in OpenVMS I64 are:

[SYSLIB]DPLI$RTLSHR.EXE
[SYSMSG]PLI$MSG.EXE
[SYSLIB]PLIRTL.IIF
[SYSLIB]PLIRTL_D56_TV.EXE

Applications and shareable images that reference the PL/I library do not work on OpenVMS I64 for Integrity servers. (Typically these are applications and shareable images that contain code written in PL/I.) This restriction applies to both native code and translated VAX and Alpha images.

See a related note in Section 2.6.

5.32 POSIX Threads Library

The following sections contain release notes pertaining to the POSIX Threads Library (formerly named DECthreads).

Also see Section A.8 for a related note.

5.32.1 Stack Overflows During Exception Handling (I64 Only)

V8.2

Exception handling on I64 systems requires considerably more stack space than it does on Alpha. When porting an application from OpenVMS Alpha, if a thread that uses exception handling does not have a generous amount of unused stack space, the thread might experience a stack overflow during exception handling on I64. Usually this appears as an improperly handled ACCVIO that is associated with one of the following operations:

• RAISE
• pthread_cancel
• pthread_exit
• A thread has an active TRY or pthread_cleanup_push block, and an OpenVMS condition is signaled (for example, as a hardware exception or using LIB$SIGNAL or LIB$STOP).

If you see such a problem, try increasing the size of the stack allocated for the thread by a small number of pages. HP recommends initially increasing the stack by 24 KB.

The default stack size has been increased by 24KB to try to address the increased stack usage on I64 systems. If your application creates a large number of threads (using the default size), the application might run out of memory resources. If this happens, you might have to increase process quotas or make application changes to reduce the number of threads that exist simultaneously.

5.32.2 THREADCP Command Behavior on I64 Systems

V8.2

The DCL command THREADCP cannot be used on OpenVMS I64 systems to query and change the two threads-related main image header flags, UPCALLS and MULTIPLE_KERNEL_THREADS. Instead, you must use the DCL commands SET IMAGE and SHOW IMAGE to set and show threads header flags on I64 systems.

Alpha users should continue to use the THREADCP command.