|
HP OpenVMS Systems Documentation |
|
HP Pascal for OpenVMS
|
| Previous | Contents | Index |
The following are command and file qualifiers that you can use when linking object modules:
/[NO]DEBUG
/NODEBUG (default)
Indicates that the VMS Debugger is to be included in the executable image and that a symbol table is to be generated. If you specify LINK/DEBUG, the program links and then executes under the control of the debugger./[NO]EXECUTABLE
/EXECUTABLE (default)
Produces an executable image. A file specification can follow /EXECUTABLE to designate a name for the image file. The /NOEXECUTABLE qualifier, which suppresses production of the image file, is useful when you want to verify the results of linking an object file before the image is produced./INCLUDE
none (default)
Specifies that the input file is an object module or a shareable image library, and that the modules named are the only ones in the library to be explicitly included as input. In the case of shareable image libraries, the module is the shareable image name. You must specify at least one module name with the /INCLUDE qualifier. The default for library modules is the .OLB file type.This qualifier is a file qualifier and cannot be used directly on the LINK command.
/LIBRARY
none (default)
Specifies that the input file is an object module or shareable image library, which the linker must search to resolve undefined symbols within other input modules specified on the same command line.You can use the /LIBRARY qualifier with the /INCLUDE qualifier to modify the same input file specification. In that case, the same library is searched for unresolved references.
This qualifier is a file qualifier and cannot be used directly on the LINK command. The default for the file to which this qualifier is applied is the .OLB file type.
/[NO]MAP
/NOMAP (interactive default)
/MAP/NOCROSS_REFERENCE (batch default)
Controls the generation of a map file and its contents. The /MAP qualifier produces a map file, which you can name by including a file specification.The map file is stored on the default device in the default directory. If you do not include a file specification with /MAP, the map file is given the name of the first input file and a .MAP file type.
With the /MAP qualifier, you can use the qualifiers /BRIEF, /FULL, and /CROSS_REFERENCE to define the type of information included in the map file.
filename/OPTIONS
none (default)
Specifies that the input file is a linker options file, which can contain input file specifications as well as special instructions recognized only by the linker. You can also use options files to create shareable images./[NO]SHAREABLE
/NOSHAREABLE (default)
Creates a shareable image. A shareable image has all of its internal references resolved, but must be linked with one or more object modules to produce an executable image. For example, a shareable image can contain a library of routines or can be used by the system manager to create a global section for all users.To include a shareable image as input to the linker, you can insert the shareable image into a shareable image library and specify the library as input to the LINK command. By default, the linker automatically searches the system-supplied shareable image library SYS$LIBRARY:IMAGELIB.OLB after searching any libraries you specify on the LINK command line. You can also include a shareable image by using a linker options file.
The /NOSHAREABLE qualifier specifies that the image produced cannot be linked with other images.
/[NO]TRACEBACK
/TRACEBACK (default)
Causes the generation of error messages to be accompanied by symbolic traceback information. This information shows the sequence of calls that transferred control to the program in which the error occurred. /NOTRACEBACK suppresses production of traceback information.The traceback capability is automatically included with the /DEBUG qualifier; therefore, if you specify both /DEBUG and /NOTRACEBACK, /NOTRACEBACK has no effect.
An object module library contains modules of program text that have been successfully compiled. To link modules contained in a object module library, use the /INCLUDE qualifier and specify the modules you want to link. For example:
$ LINK GARDEN,VEGETABLES/INCLUDE=(EGGPLANT,TOMATO, BROCCOLI,ONION) |
Besides program modules, an object module library can also contain a symbol table with the names of each global symbol in the library, and the name of the module in which they are defined. You specify the name of the object module library containing symbol definitions with the /LIBRARY qualifier. When you use the /LIBRARY qualifier during a link operation, the linker searches the specified library for all unresolved references found in the included modules during compilation.
Also, by default, the linker automatically searches the system-supplied shareable image library SYS$LIBRARY:IMAGELIB.OLB after searching any libraries you specify on the LINK command.
In the following example, the linker uses the library RACQUETS to resolve undefined symbols in BADMINTON, TENNIS, and RACQUETBALL.
$ LINK BADMINTON, TENNIS, RACQUETBALL, RACQUETS/LIBRARY |
The RUN command executes programs that have been linked into an executable image by the OpenVMS Linker. This command has the following format:
|
RUN [/command-qualifier] file-spec |
/command-qualifier
The name of a qualifier that indicates special processing to be performed by the linker on all files listed.file-spec
The name of the executable image you want to run. The default file type for executable images is .EXE.
The image activator accepts one command qualifier, as follows:
/[NO]DEBUG
depends on linking (default)
The /[NO]DEBUG qualifier is optional. Specify the /DEBUG qualifier to request the debugger, if the image was not linked with it. You cannot use /DEBUG on images linked with the /NOTRACEBACK qualifier. If the image was linked with the /DEBUG qualifier and you do not want the debugger to prompt, use the /NODEBUG qualifier. The default action depends on whether you specified /DEBUG on the LINK command line.
Consider the following examples:
$ RUN PROG |
$ RUN/NODEBUG PROG |
During program development, you can have to respond to messages regarding possible syntax or logic errors in your program. These messages have the following form:
%SOURCE-CLASS-MNEMONIC, message_text |
SOURCE
A code that identifies the origin of the message. For example, the PASCAL code identifies the HP Pascal compiler, and the PAS code identifies the HP Pascal run-time system.CLASS
A single character that determines message severity. The four classes of error messages are: Informational (I), Warning (W), Error (E), and Fatal (F). The definition for each class depends on the source of the message, but execution of your request does not continue when E- or F-level errors occur.MNEMONIC
A name that is unique to that message.message_text
Explains the event that caused the message to be generated.
For example, a common linker error occurs when you omit required file or library names from the command line, and the linker cannot locate the definition for a specified global symbol reference. The following error messages appear when a main program in OCEAN.OBJ calls a subprogram in SEAWEED.OBJ that is not specified in the LINK command:
%LINK-W-NUDFSYMS, 1 undefined symbol %LINK-I-UDFSYMS, SEAWEED %LINK-W-USEUNDEF, module "OCEAN" references undefined symbol "SEAWEED" %LINK-W-DIAGISUED, completed but with diagnostics |
Pascal allows you to divide your application into subprograms by creating procedures and functions. HP Pascal allows you further modularity by allowing you to create compilation units, called programs and modules, that can be compiled separately. This chapter discusses the following topics about separate compilation:
The sections at the beginning of this chapter use code fragments from the examples in this chapter and in the online example directory, which by default is PASCAL$EXAMPLES. |
To divide your program into a program and a series of modules, you need to decide, according to the needs of your application, which data types, constants, variables, and routines need to be shared either by other modules or by the program. To share data, create an environment file by using the ENVIRONMENT attribute in a module. Consider the following example:
{
Source File: share_data.pas
This program initializes data to be shared with another compilation
unit.
}
[ENVIRONMENT( 'share_data' )]
Module Share_Data;
CONST
Rate_For_Q1 = 0.1211;
Rate_For_Q2 = 0.1156;
Rate_For_Q3 = 0.1097;
Rate_For_Q4 = 0.11243;
TYPE
Initialized_Type = ARRAY[1..10] OF INTEGER VALUE
[1..5: 67; 6,9: 105; OTHERWISE 33];
END.
|
If you do not specify a file name, HP Pascal creates an environment file using the file name of the source file and a default extension of .PEN. Another compilation unit can access the types and constants in the previous example by inheriting the environment file, as follows:
{
Source File: program.pas
This code inherits data declarations and uses them in a program.
}
[INHERIT( 'share_data' )]
PROGRAM Use_Data( OUTPUT );
VAR
a, b, c : Initialized_Type;
Total : REAL VALUE 0.0;
BEGIN
Total := Total + ( Total * Rate_For_Q3 );
WRITELN( b[7] ); {b is of an initialized type}
END.
|
To build and run the application made up of the code in the previous examples, use the following commands:
$ PASCAL SHARE_DATA
$ PASCAL PROGRAM
$ LINK PROGRAM
$ RUN PROGRAM
33
|
If a module contains variable declarations, routine declarations, schema types, or module initialization or finalization sections, you must link the program with the module that created the environment file to resolve external references. To prevent errors, you may wish to link programs with modules of inherited environment files as standard programming practice. For example, if SHARE_DATA contained a variable declaration, you must enter the following to resolve the external reference:
$ PASCAL SHARE_DATA
$ PASCAL PROGRAM
$ LINK PROGRAM, SHARE_DATA
$ RUN PROGRAM
33
|
For many applications, it is a good idea to place all globally accessible data into one module, create a single environment file, and inherit that module in other compilation units that need to make use of that data. Using environment files in this way reduces the difficulties in maintaining the data (it is easier to maintain one file) and it eliminates problems that can occur when you cascade environment files. If compilation unit A inherits an environment file from compilation unit B, and if unit B inherits a file from unit C, then inheritance is cascading. Figure 2-1 shows a cascading inheritance path and a noncascading inheritance path.
Figure 2-1 Cascading Inheritance of Environment Files
Cascading is not always undesirable; it depends on your application and on the nature of the environment files. For example, if cascading occurs for a series of constant and type definitions that are not likely to change, cascading may require very little recompiling and relinking. However, if the constant and type definitions change often or if environment files contain routines and variables, you may find it easier to redesign the inheritance paths of environment files due to the recompiling and relinking involved.
Also, the inheritance path labeled Efficient in Figure 2-1 is not immune to misuse. That inheritance path, although it avoids the problems of cascading, may still involve multiply declared identifiers (identical identifiers contained in several of the compilation units whose environment files are inherited by compilation unit 4).
In many instances, HP Pascal does not allow multiply declared identifiers in one application. For example, a compilation unit cannot inherit two environment files that declare the same identifier; also, a compilation unit usually cannot inherit an environment file that contains an identifier that is identical to an identifier in the outermost level of the unit (one exception, for example, is the redeclaration of a redefinable reserved word or of an identifier predeclared by HP Pascal). Also, HP Pascal allows the following exceptions to the rules concerning multiply declared identifiers:
If a compilation unit creates an environment file and if it contains data that you do not want to share with other compilation units, you can use the HIDDEN attribute. Consider the following example:
[ENVIRONMENT]
MODULE Example;
TYPE
Array_Template( Upper : INTEGER ) =
[HIDDEN] ARRAY[1..Upper] OF INTEGER;
Global_Type : Array_Template( 10 );
VAR
i : [HIDDEN] INTEGER; {Used for local incrementing}
PROCEDURE x;
BEGIN
i := i + 1;
END;
PROCEDURE y;
BEGIN
FOR i := i + 1;
END;
END.
|
The code in the previous example hides the schema type, preventing the schema type from being used in inheriting modules. (Whether to hide the type depends on the requirements of a given application.) Also, HP Pascal does not include the variable i in the environment file; this allows inheriting modules to declare the identifier variable i as an incrementing variable without being concerned about generating errors for a multiply defined identifier.
HP Pascal performs compile-time and link-time checks to ensure that all compilations that inherit environment files actually used the same environment file definition. Information is placed in the object file such that the OpenVMS Linker performs the same check between each object file that inherited environment files.
By default, compilation units that inherit an environment file compare the embedded compilation time inside the environment file:
If the times are different, a compile-time message is displayed.
This checking can be disabled or modified by using the PEN_CHECKING_STYLE attribute in the Pascal source file that created the environment file. Once the environment file exists, its selected checking style will be performed at each use.
The PEN_CHECKING_STYLE attribute is valid at the beginning of a MODULE that creates an environment. The syntax is:
PEN_CHECKING_STYLE(keyword) |
In this format "keyword" is:
When HP Pascal compiles a module with the /ENVIRONMENT qualifier or [ENVIRONMENT] attribute, it generates an environment file and an object file. This is also true when compiling a or program, although it is not customary to generate an environment from a program. The PEN file contains compressed symbol table information and is used by subsequent Pascal compilations with the INHERIT attribute.
Neither the OpenVMS Linker or ANALYZE/OBJECT reads environment files. Only the HP Pascal compiler uses these files. The OBJ file contains the following:
It is possible for the OBJ file to contain just the linker timestamp record for the environment being created. Since the linker does not require the timestamp record for correct behavior, you may not need the OBJ file created when generating a PEN file however, if the module is used inherited variables or routines, then the OBJ file is needed at link time. This applies not only to the environments inherited by the program, but also to any environments inherited by modules which create subsequent environments.
With the addition of schema types and TO BEGIN DO and TO END DO sections, the decision on which OBJ files to include on the LINK command becomes more complicated. This is due to:
The rule is still basically "Use any OBJ whose module contained variables or routines" but now you must consider compiler-generated variables or routines, as well as user-defined variables or routines. Depending on the modules involved, missing OBJ files might not be detected by the linker, since PROGRAMs do not directly call their inherited initialization routines.
Compiling with the /DEBUG qualifier might require more OBJ files to be included on the LINK command. Normally, the compiler only uses the inherited compiler-generated variables and routines if the corresponding schema types are used in certain Pascal constructs. However, the Debug information generated to describe the schema types always requires the compiler-generated variables and routines. This is because a user might ask the Debugger to perform some operation on the variable that did not appear in the source code. Therefore, if you omitted an OBJ file on the LINK command and did not get a linker error, you might get an error if the /DEBUG qualifier was used.
All OBJ files from modules creating environments must be included on the LINK command line if they contain variables or routines (either user-generated or compiler-generated). To receive the full benefit of the linker's timestamp verification, you should include all OBJ files on the LINK command.
| Previous | Next | Contents | Index |