HP OpenVMS Systems Documentation
HP OpenVMS Version 8.3 New Features and Documentation Overview
5.6 Linker Utility Enhancements
The object modules generated by C, C++, Ada, and possibly other compilers can have symbol names in the symbol table that have been altered; a process that is commonly referred to as "mangling". These names are the symbol names visible to the linker, which the linker uses for symbol resolution.
The reason for mangling can be an overload feature in the programming language or simply the need to uniquely shorten names. When you link such modules and get an undefined-symbol message, the linker displays only the symbol name from the object module's symbol table (that is, the mangled name). This processing makes it difficult to match the undefined, mangled symbol with the demangled, source code name. Therefore, to support upcoming compilers that produce display-name information (DNI), the linker can now process that information. In addition, the linker displays the source code name; that is, the linker can demangle the undefined symbol name. Further, if there is demangling information for universal symbols (that is, those to be exported from a shareable image), the linker can include that information in the generated shareable images.
The symbol resolution process remains unchanged. The linker still uses the mangled symbol names for symbol definitions and to resolve symbol references. The symbol vector option remains the same as well; it still requires the names found in the symbol tables---the mangled names.
You can use the new command-line qualifier, /DNI, to control the processing of the demangling information. Specify /DNI (the default) to allow the linker to attempt symbol-name demangling and move the necessary demangling information into the shareable image being created. Specify /NODNI when:
You can request a new map section containing a translation table for the global symbol definitions. This table correlates the mangled symbol names with their demangled equivalents. By default, the linker does not generate this section in the map file. To request this section, specify the key word DEMANGLED_SYMBOLS to the /FULL qualifier. As with other keywords for the /FULL qualifier, specify the /MAP qualifier. Finally, specify the /DNI qualifier. The translation table in the map can be helpful to verify the symbol vector entries.
The following edited example shows how the demangled name is displayed in a linker message:
The demangling information section is part of the object module or
shareable image. The information needed to demangle the symbol name can
be entirely contained within that section, or that information can
include the name of a facilitator routine name and shareable image name
to perform the demangling. This shareable image is usually located in
SYS$LIBRARY and is provided by the language run-time environment
already present on OpenVMS or is provided during the installation of
the language compiler. If the facilitator routine is required, the
linker attempts to activate the image and call the routine. If this
fails at any point---for example, if the routine is not found in the
shareable image or the image could not be located---then the linker
displays an informational message indicating the problem. The link
operation, as well as propagation of the demangling information into a
shareable image, is independent of the success or failure of calling
the facilitating routine.
The LIBRARY command now accepts the /DEMANGLED_SYMBOLS qualifier. When you use this qualifier, the Librarian lists symbols from an ELF object or ELF shareable image library that were altered by a language processor (also known as mangling) and prints their corresponding demangled name (that is, the name found in the source code). Mangled names are output as external symbols from an object module (or, as universal symbols from a shareable image). One reason for the language processor to mangle names is function overloading; a feature of the C++ language.
The Librarian stores the symbols that are emitted from an object module or shareable image. These symbols may include mangled symbols. The information needed to demangle these symbol names, along with a possible name of a facilitating shareable image, is contained in the object module or shareable image.
For an ELF object library, object modules are fully contained in the library. To retrieve the demangling information, the object module is mapped into memory and searched. It may be the case that language-specific demangling shareable images are also mapped into memory and activated. The symbols are read from the object library module and demangled with the information provided by the module. The library's symbol-name table is scanned to mark which of the object library module's symbols are in the library's symbol-name table. Subsequent modules are processed in the same way, and a listing is then generated.
For ELF shareable image libraries, the shareable image is not stored in the library. This is similar to OpenVMS Alpha and OpenVMS VAX shareable image libraries. Instead, only the exported symbols and other minimal information is stored in the library. As a result, the Librarian searches for the shareable image, external to the library, in order to obtain the demangling information.
The Librarian performs a three-step search; stopping when it successfully obtains a file:
You can use the existing /OUTPUT= qualifier to direct the generated output from the demangling process to a file specification you choose. When you do not specify the /OUTPUT= qualifier, the Librarian by default places the output into a file in the current disk and directory, with the filename the same as the filename of the library and the extension .LIS as the file type.
You can also limit which library modules are selected for demangling by using the existing /ONLY= qualifier.
For example, to display the demangled symbols from an object library and have the output sent to the terminal screen, enter the following DCL command at the command line prompt:
The following example captures the demangled symbol output to the file DUMP.LIS of the SHAREIMG.OLB shareable image library:
The following example captures the demangled symbol output to the default file specification SYS$DISK:SHAREIMG.LIS of the SHAREIMG.OLB shareable image library:
The following example captures the demangled symbol output to the default file specification SYS$DISK:OBJLIB.LIS of the object module MY_OBJ in the OBJLIB.OLB object library:
5.8 HP MACRO Compiler for OpenVMS Alpha Systems
The MACRO compiler has been upgraded to use the latest GEM backend for Alpha systems. In addition, several enhancements have been made:
5.9 Record Management System (RMS) Enhancements
The following sections describe the RMS enhancements provided in
OpenVMS Version 8.3.
The CONVERT/FDL and CREATE/FDL routines have been enhanced to allow an FDL string to be passed as the FDL file specification. If the /FDL qualifier value is a quoted string and is not a quoted POSIX pathname, then it is passed to the FDL parser as an FDL string. Quoted values within the string must be designated with double quotes. See the HP OpenVMS Utility Routines Manual FDL section for details of using an FDL string.
Note the following examples:
5.9.2 RMS Global Buffer Enhancements for Indexed Files
Prior to the OpenVMS Version 8.3 release, RMS global buffers were exclusively mapped to P0 (32-bit address) space. This restricted the overall per-process limit to less than 1 GB for the total number of global buffers specified for all files accessed by a process. This per-process limit forced RMS users to compromise on the number of global buffers specified for each file. It also constrained the per-file maximum size allowed for a global cache (currently, 32767 buffers).
To improve the overall scalability and performance of RMS global buffers, this release introduces the following global buffer enhancements for indexed files:
Because RMS global buffers are local to each node, these enhancements
were designed so they could be implemented on OpenVMS Alpha and OpenVMS
for Integrity servers Version 8.3 nodes in a mixed cluster environment
without requiring any changes to OpenVMS VAX or earlier version nodes.
The Version 8.3 Alpha and Integrity server nodes will be able to
increase the global cache size on an indexed file, while other nodes
continue to operate on the file with the pre-Version 8.3 global cache
size. This is particularly attractive, because it allows users to phase
in Version 8.3 (or later) Alpha or Integrity server nodes that can
support larger global buffer caches for indexed files into clusters
with earlier versions of OpenVMS, including nodes running OpenVMS VAX.
There are now two forms of the SET FILE/GLOBAL_BUFFER command:
For example, the following commands do four distinctly different things:
Global buffers specified with the old syntax (SET FILE/GLOBAL_BUFFER=n) stores settings in the file header in one location, while the new syntax (SET FILE/GLOBAL_BUFFER=keyword[=n]) are stored elsewhere in the file's header and are used to implement the new variation of global buffers, allowing more buffers and automatic adjustments for file growth.
Note You can specify only one version of the global buffer qualifier in a command string. Here's an example of using both the old and new global buffer specifications to set the old compatibility global buffer count value (for OpenVMS versions prior to Version 8.3) to 100 and the new value (Version 8.3 and later) to 10000:
In a clustered environment with mixed OpenVMS versions, the same file
can be opened on different nodes with different global buffer counts.
For nodes prior to Version 8.3, use the old compatibility setting, and
for Version 8.3 nodes and later use the new values.
Two new fields have been added to the read-only XABFHC (file header characteristics):
The field descriptions for these fields are the following:
5.9.5 New RMS Field Values
The following field values have been added:
Figure 5-1, from the HP OpenVMS I/O User's Reference Manual, has been updated to reflect the new fields.
Figure 5-1 ACP-QIO Record Attributes Area
5.9.6 New RMS Per-File Management Options for Sizing Global Buffer Cache
This release introduces two new per-file management options that allow simpler sizing of the global buffer cache for all RMS file organizations (sequential, relative, and indexed). These new options augment the existing global buffer count option:
The RMS global buffer count (GBC) default is based on an algorithm that uses two new global buffer (GB) SYSGEN parameters: GB_CACHEALLMAX and GB_DEFPERCENT. If the default option is enabled, and if the size (in blocks) of the file is less than or equal to the size specified for the GB_CACHEALLMAX parameter, RMS allocates sufficient global buffers to cache the whole file.
If the size (in blocks) is greater than the specified size for the
GB_CACHEALLMAX parameter, RMS allocates sufficient global buffers to
cache the percentage of the file specified by the GB_DEFPERCENT (global
buffer default percent) parameter. A percentage greater than 100
percent can be specified to provide space in the cache for the file to
The XAB$_GBC item code can be used with an item list XAB on a $CONNECT or $DISPLAY with a SENSEMODE operation to sense the actual number of global buffers connected to a file when the global section for the file was created by the first accessor on the respective node.
The XAB$_GBC item code requires a 4-byte buffer to return the cache size that was connected. You cannot use a SETMODE with this item.
This option is not supported for DECnet operations; it is ignored.
The XAB$_GBC32 item code can be used with an item list XAB on a $CREATE with A SETMODE operation. It sets the longword global buffer count as a permanent attribute in the record-attribute area of the file header when a file is created. You can also use it with an item list XAB on a $CONNECT with a SETMODE to override at run time the permanent attribute in the file header. The override applies only if the process is the first connector of the cache on the respective node.
You cannot sense the global buffer count connected to a file using the XAB$_GBC32 item code. Use the XAB$_GBC item code to sense the actual global-buffer count.
The XAB$_GBC32 item code requires a 4-byte buffer to store the cache size that can be requested as either an actual count or a percentage of the total number of blocks in the file at run time. To specify the cache size as a percent, the XAB item list must also include the XAB$_GBCFLAGS item code; otherwise, the cache size value provided with the XAB$_GBC32 item code is interpreted as a count.
You can specify a maximum value of %x7FFFFFFF as the count for an indexed file; sequential and relative file organizations are restricted to a maximum of 32767. You can specify a percentage that is greater than 100 percent to allow for rapid growth for a file that, once opened, is closed infrequently.
Note that this option is not supported for DECnet operations; it is
The XAB$_GBCFLAGS item code can be used with an item list XAB on a $CREATE with a SETMODE operation. It sets the global buffer flags value as a permanent attribute in the record attributes area of the file header when a file is created. You can also use it with an item list XAB on a $CONNECT with a SETMODE to override at run time the permanent attribute in the file header. The override applies only if the process is the first connector of the cache on the respective node.
You can sense the global buffer flags value using the XAB$_GBCFLAGS item code with an item list XAB on a $CONNECT or $DISPLAY with a SENSEMODE operation. The global buffer flags used in calculating the global buffer count when the global section for the file was created by the first connector is returned.
The two available flags are:
The XAB$_GBCFLAGS item code requires a 4-byte buffer to store the flag value of either XAB$_GBC_PERCENT or XAB$_GBC_DEFAULT.