HP OpenVMS Systems Documentation
HP OpenVMS Linker Utility Manual
In this example, the linker appears to loop. The file DOES_NOT_EXIST.OBJ, as included in the argument list, does not exist. An RMS_RELATED_CONTEXT= option is not specified (and, therefore, defaults to YES). With multiple logical names and a search list for the logical RESD$, determining that this file is missing takes very long.
If you do not specify the STACK= option, the linker allocates 20 pagelets (512-byte units) for the user-mode stack. Note that the stack is usually located at the lower end of the used P1 space and that additional space for the user-mode stack is automatically allocated - growing into unused, lower P1 space, if needed, during program execution.
Directs the linker to define an absolute global symbol with the specified name and assign it the specified value. You can use this option to specify a link-time constant.
The definition of a symbol specified by the SYMBOL= option constitutes the first definition of that symbol, and it overrides subsequent definitions of the symbol in input object modules. In particular:
SYMBOL_TABLE= (I64 and Alpha)
For I64 and Alpha linking, specifies whether the linker should include global symbols in a symbol table file produced in a link operation in which a shareable image is created. By default, the linker includes only universal symbols in a symbol table file associated with a shareable image.
This option may be specified only in the creation of a shareable image. Note that the symbol table file affected by this option cannot be used as input in a subsequent link operation but is intended to be used with the OpenVMS System Dump Analyzer utility (SDA) as an aid to debugging.
SYMBOL_VECTOR= (I64 and Alpha)
1You can specify an alias name for this type of symbol vector entry.
2Although not a symbol, the name of an exported program section is part of the GST, which implements the public interface of the shareable image.
The linker creates an entry in the GST of a shareable image for each name listed in the SYMBOL_VECTOR= option, unless the symbol is declared private, the /NOGST qualifier is specified, or the symbol is the internal name for an alias. Symbols and program sections that appear in the GST of a shareable image are available for external modules to link against. For more information about creating and using shareable images, see Chapter 4 (I64) and Chapter 8 (Alpha).
UNIVERSAL= (VAX Only)
For VAX linking, declares a symbol in a shareable image as universal, causing the linker to include it in the global symbol table of a shareable image.
This option may be specified only in the creation of a shareable image.
This glossary defines key terms for the OpenVMS Linker. The OpenVMS
Linker is part of the OpenVMS operating system which is available on
Integrity, Alpha, and VAX hardware platforms. Certain terminology
commonly used by the linker on Alpha and VAX might be different on
OpenVMS I64. Where applicable, cross-references are made between
Alpha/VAX systems and I64 systems.
based cluster: Alpha and VAX systems. A cluster
located at a base address using the CLUSTER= option.
brief map: Information produced by the linker when the
/BRIEF qualifier is specified with the /MAP qualifier. A brief map
contains only a subset of the default map. See also image
default map: Information produced by the linker when
the /MAP qualifier is specified without the /BRIEF and /FULL
qualifiers. See also image map.
demangler: A compiler tool that translates mangled
names back to their source-name equivalents. Recent compilers are able
to include demangling information when they generate their object
modules. See also mangled name.
ELF: See Executable and Linkable Format (ELF).
Executable and Linkable Format (ELF): The object and
image format as described in System V Application Binary Interface. The
ELF format is extensible; that is, it can contain hardware and software
extensions. For I64 systems, a hardware extension is used as described
in the Intel Itanium Processor-specific Application Binary Interface.
Based on that interface, a software extension to ELF is provided for
OpenVMS systems (see the IPF/VMS Object/Image File Functional
Specification). In the OpenVMS I64 extension, ELF is the object
and image file format for object and image binaries. Compilers,
assemblers, and other language processors whose output is used by the
used by the OpenVMS Linker Utility must produce object files that
conform to the OpenVMS extension of the ELF specification.
executable image: The primary type of image created
from a link operation. This image can be executed from the DCL command
line. See also shareable image.
fix-up: Executable and shareable images can have
references to shareable images. At link time, when symbols are
resolved, the address values are not known. They become visible when
the image activator maps the shareable image. At that time, the image
activator "fixes up" the references with the address values.
full map: Information produced by the linker when the
/FULL qualifier is specified with the /MAP qualifier. To tailor the
full information, you can use keywords to add or suppress specific
information. See also image map.
function descriptor: An I64 term. As defined in the
OpenVMS I64 Calling Standard, a function descriptor is the pairing of a
code address and a global pointer. With this information, a call to the
function (or procedure) can be made, and the called function can access
its data by way of the global pointer.
hard definition: A symbol with compiler-supplied
storage that is not in an overlaid section.
header table: An ELF term. The ELF format describes
portions of the object and image modules, as well as their attributes,
using section and segment headers. These headers are contained in two
arrays of headers called the Section Header Table (for section headers)
and the Program Header Table (for program segment headers). Only one
header, the main ELF header, is not listed in either of these tables.
It is located at the beginning of the module. See also
Executable and Linkable Format.
image file: A file containing binary code and data of
a program for an OpenVMS system; essentially, an image of what is in
memory when the program is started. Also called an image.
image header: An Alpha and VAX term. The part of an
executable or shareable image that describes the contents of the image
file (the image sections). It is located at the beginning of the file.
image initialization: The part of the link operation
where the linker, after it resolves references and obtains memory
requirements, initializes the image by filling it with the compiled
binary code and data.
image map: Information generated by the linker that
describes the contents of the image and the linking process. The image
map helps you determine programming and link-time errors, study the
layout of the image in virtual memory, and keep track of global
symbols. You control the information generated by the map by accepting
the default map, or by specifying either a brief or full map. See
also default map, full map, brief map.
image optimization: An I64 and Alpha term. Actions the
linker takes to improve run-time performance of an image it creates.
For example, for OpenVMS I64 images, the linker can optimize data
references to the short data segment.
image relocations: Address suggested by the linker
that that image activator uses to relocate the image. See
linkage pair: An Alpha term. A compiler-generated
small data structure to implement a call. A linkage pair consists of
the required information to make a call: the code address and the
procedure descriptor address of a procedure. The linkage pair is not
defined in the OpenVMS Alpha Calling Standard. It is an implementation
detail used by compilers and understood by the linker.
local function descriptor: An I64 term. As defined in
the OpenVMS I64 Calling Standard, a function descriptor is the pairing
of a code address and a global pointer. With this information, a call
to the function (or procedure) can be made and the called function can
access its data by way of the global pointer. The calling standard
requires a local function descriptor for each call to another image.
Local function descriptors are set up by the linker. Although for each
call a different local function descriptor can be used, the linker sets
up and re-uses one local function descriptor per target function. The
linker creates a fix-up for each local function descriptor. See
also fix-up, official function descriptor.
mangled names: The process where some compilers create
abbreviated symbol names to implement language features or to use
shortened, unique names. For example, C++ compilers mangle symbol names
to guarantee unique names for overloaded functions. See also
object file: A file produced from a source language by
a language processor (compiler, assembler, etc.) that contains one or
more object modules that serves as input to the linker. See
also image file.
official function descriptor: An I64 term. As defined
in the OpenVMS I64 Calling Standard, a function descriptor is the
pairing of a code address and a global pointer. With this information,
a call to the function (or procedure) can be made and the called
function can access its data via the global pointer. The linker sets up
an official function descriptor to implement calls to the function (or
procedure). As such, an official function descriptor is an entry point.
An entry is unique: there can be only one official function descriptor
per function (or procedure). See also local function
OpenVMS system: An HP system running the HP OpenVMS
operating system. These include OpenVMS I64, Alpha, and VAX operating
systems. See also system.
OpenVMS Alpha system: An HP Alpha system running the
OpenVMS Alpha operating system. Also referred to as Alpha system or
OpenVMS I64 system: An HP Integrity server running the
OpenVMS I64 operating system. Also referred to as I64 system or I64.
OpenVMS VAX system: An HP VAX system running the
OpenVMS VAX operating system. Also referred to as VAX system or VAX.
platform: A generic term referring to all systems of a
specific processor architecture. For example, Intel Itanium. (See
privileged shareable image: A shareable image
containing privileged code. For example, user-written system services
allow user-mode programs to call routines that can perform functions
that require privileges. These services are implemented in shareable
images. Because of the presence of privileged code, they are referred
to as privileged shareable images. See also protected
program section: An area of memory that has a name, a
length, and other attributes describing the intended or permitted usage
of that portion of memory. Program sections are part of an object
module. At link time, the user can set or change some of the attributes
so the linker combines them in a manner that the user controls.
program segment: An I64 term. A chunk of the image
binary, usually data or code. In general, everything that needs to be
available to activate and run the image. See also image
protected shareable image: A shareable image created
with the /PROTECT qualifier. Privileged shareable images must be
protected from user-mode and supervisor-mode write access. See
also privileged shareable image.
psect: See program section.
relaxed definition: See tentative definition.
relocations: The linker combines object binaries (code
and data) from different object modules. The language processors do not
know where their modules will be located in virtual address space.
Therefore, the language processors generate information packets for the
linker, called relocations, so that code execution and data references
will work from any linker-chosen memory location. The linker applies
these relocations to data. Because the image activator can place an
image at any memory location, the linker produces relocations, called
"image relocations", to assist the image activator. Code is always
position independent, that is, it requires no relocations.
shareable image: A collection of data and program
services that is a product of a link operation and is not directly
executed from the DCL command line. To make use of a shareable image,
it must first be included as input in a link operation that produces an
executable image. See also executable image.
symbol resolution: The process of resolving references
to symbols whose definitions are external to the module.
system: The computer hardware; the server. Distinguish
from the operating system (for example, OpenVMS Alpha). See
system image: An Alpha and VAX term. A product of a
link operation producing an image that can be run as a standalone
program, without operating system support. Therefore, these images
typically do not contain image activation information. On OpenVMS I64,
images always contain image activation information. As a result, the
I64 linker does not create system images. See also
tentative definition: A symbol definition without compiler supplied storage or storage in overlaid sections. There can be tentative definitions for a symbol in several modules. If no hard definition for the symbol is encountered, one of the tentative definitions for that symbol is selected by the linker to be the defining instance. See also hard definition.