|
HP OpenVMS Systems Documentation |
|
HP OpenVMS Linker Utility Manual
5.2.8 Link Run Statistics SectionThe Link Run Statistics section contains miscellaneous statistical information about the link operation, such as performance indicators. Example 5-7 shows the formatting of this section. Note that the link command line and the linker options are part of the Link Run Statistics Section.
The following description corresponds to the callout number in the preceding linker map figure:
The following example demonstrates how to read the footnotes. The long names were constructed for demonstration purpose only. In Example 5-8, the qualifiers /MAP/CROSS/FULL were specified to get both the cross-reference and the symbol value list.
The items in the following list correspond to the numbered items in the preceding figure:
Example 5-9 shows an example of a Cross Reference Footnotes section, automatically added by the linker.
5.4 Translation Table for Mangled NamesSome compilers mangle symbol names to implement language features (for example, overloading) or to use shortened, unique names. Ada and C++ compilers, for example, do so. The linker receives only mangled names from the compilers for resolving symbols and for exporting universal symbols. There is no general rule to derive a mangled name from a source code name or vice versa. If you need to know the source code name for a given mangled name, you need the demangler support from that programming language processor. Recent compilers are able to add demangling information to the object modules. With this information and the language specific demangler routines (usually available with run-time libraries), the linker can create a translation table for mangled names. To obtain this table, use the DEMANGLED_SYMBOLS keyword for the /FULL qualifier when requesting a map. The linker lists all the global symbol definitions from the input object modules with their source code names. Example 5-10 shows a translation table in the linker map.
Part 3
|
In some HP programming languages, certain types of global symbols, such as external variables in C and COMMON data in FORTRAN, are not listed in the GSD as global symbol references or definitions. Because these data types implement virtual memory that is shared, the languages implement them as program sections that are overlaid. These symbols appear as program section definitions in the GSD, not as a symbol definition or reference. (Compilers use program sections to define the memory requirements of an object module.) The linker does not include program section definitions in its symbol resolution processing. For information about how the linker processes program sections, see Chapter 7. |
On VAX systems, the VAX C language extensions globalref and globaldef allow you to create external variables that appear as symbol references and definitions in the GSD. For more information, see the VAX C documentation.
On Alpha systems, the HP C compiler supports the globalref and
globaldef language extensions. In addition, HP C supports command line
qualifiers and source code pragma statements that allow you to control
whether it implements external variables as program sections or as
global symbol references and definitions. For more information, see the
HP C documentation.
6.1.2 Linker Symbol Resolution Processing
During its first pass through the input files specified in the link operation, the linker attempts to find the definition for every symbol referenced in the input files. By default, the linker processes all the global symbols defined and referenced in the GSD of each object module and all the universal symbols defined and referenced in the GST of each shareable image. The definition of the symbol provides the value of the symbol. The linker substitutes this value for each instance where the symbol is referenced in the image.
The value of a symbol depends on what the symbol represents. A symbol can represent a routine entry point or a data location within an image. For these symbols, the value of the symbol is an address. A symbol can also represent a data constant (for example, X = 10). In this case, the value of the symbol is its actual value (in the example, the value of X is 10).
For symbols that represent addresses in object modules, the value is expressed initially as an offset into a program section. This is how language processors express addresses. Later in its processing, when the linker combines the program sections contributed by all the object modules into the image sections that define the virtual memory layout of the image, it determines the actual value of the address. (For information about how the linker determines the virtual memory layout of an image, see Chapter 7.)
For symbols that represent addresses in a shareable image, the value of the symbol at link time is architecture specific.
For Alpha images, at link time, the value of a symbol in a shareable image (as listed in the GST of the image) is the offset of the symbol's entry in the symbol vector of the image. A symbol vector entry is a pair of quadwords that contain information about the symbol. The contents of these quadwords depend on whether the symbol represents a procedure entry point, data location, or a constant. Figure 6-1 illustrates the contents of a symbol vector entry for each of these three types of symbols. Note that, at link time, a symbol vector entry for a procedure entry point or a data location is expressed as an offset into the image. At image activation time, when the image is loaded into memory and the base address of the image is known, the image activator converts the image offset into a virtual address. Figure 6-1 shows the contents of the symbol vector at link time and at image activation time.
Figure 6-1 Symbol Vector Contents
Note that the linker does not allow programs to make procedure calls to symbols that represent data locations.
For VAX images, at link time, the value of a symbol in a shareable image (as listed in the GST of the image) is the offset into the image of the routine or data location, if the symbol was declared universal using the UNIVERSAL= option. If the symbol was declared universal using a transfer vector, the value of the symbol is the offset into the image of the transfer vector entry. If the symbol represents a constant, the GST contains the actual value of the constant.
The actual value of an address symbol in a shareable image is determined at run time by the image activator when it loads the shareable image into memory. The image activator relocates all the address references within a shareable image when it loads the image into memory. Once it has determined the absolute values of these addresses, the image activator fixes up references to these addresses in the image that linked against the shareable image. Previously, the linker created fix-ups that flag to the image activator where it must insert the actual addresses to complete the linkage of a symbolic reference to its definition in an image. The linker listed these fix-ups in the fix-up section it creates for the image. (For more information about shareable images, see Chapter 8.)
For VAX images, you can specify the address at which you want a shareable image loaded into memory by using the BASE= option. When you specify this option, the linker can calculate the absolute addresses of symbols within the shareable image because the base address of the shareable image is known. By specifying a base address, you eliminate the need for the image activator to perform fix-ups and relocations.
Note, however, that basing a shareable image can potentially destroy upward compatibility between the shareable image and other images that were linked against it.
Figure 6-2 illustrates the interdependencies created by symbolic references among the modules that make up an application. In the figure, arrows point from a symbol reference to a symbol definition. (The statements do not reflect a specific programming language.)
Figure 6-2 Symbol Resolution
The linker creates an image even if it cannot find a definition for every symbol referenced in the input files it processes. The linker reports these undefined symbols as in the following example, if at least one of these unresolved references is a strong reference. (For information about strong and weak symbolic references, see Section 6.5.) The linker includes the message in the map file, if a map file was requested.
$ link my_main ! The module MY_MATH is omitted %LINK-W-NUDFSYMS, 1 undefined symbols: (1) %LINK-I-UDFSYM, MYSUB (2) %LINK-W-USEUNDEF, undefined symbol MYSUB referenced in psect $CODE offset %X0000001A in module MY_MAIN file WORK:[PROGRAMS]MY_MAIN.OBJ;1 |
If you run an image that contains undefined symbols and the symbols are never accessed, the program will run successfully. If you run an image that contains undefined symbols and the image accesses the symbols at run time, the image will abort, in most cases, with an access violation because the linker assigns the value zero to undefined symbols, as in the following example:
$ run my_main %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000, PC=00001018, PSL=03C00000 %TRACE-F-TRACEBACK, symbolic stack dump follows module name routine name line rel PC abs PC MY_MAIN main 15 00000018 00001018 |
| Previous | Next | Contents | Index |