HP OpenVMS Systems Documentation

The Alpha object language currently defines seven types of header records. Each type is assigned a symbolic code with values between 0 and 6. All other values are illegal in an Alpha object module.

Table B-4 lists the various types of header records.

The content and format of the MHD and LNM header subtypes, both of which are required in each object module, are described in the following subsections. Figure B-2 depicts a module header with MHD and LNM subrecords.

Figure B-2 Module Header Record with Subrecords

Though currently ignored by the linker, the header subtypes SRC, TTL, CPR, MTC, and GTX exist to allow the language processors to provide printable information within the object module for documentation purposes.

The format of the LNK, SRC, TTL, CPR, MTC, and GTX records consists of a record type field (EOBJ$W_RECTYP) containing the value EOBJ$C_EMH, a record size field (EOBJ$W_SIZE), a header subtype field (EOBJ$W_SUBTYP), and a field containing the uncounted ASCII text.

The content and format of the SRC and TTL records are depicted in subsections B.2.3 and B.2.4, respectively. The contents of these records, as well as the MTC record (which contains information about the maintenance status of the object module), are displayed in an object module analysis. (See the description of the ANALYZE/OBJECT command in the OpenVMS DCL Dictionary.)

B.2.1 Main Module Header Record (EMH$C_MHD)

The main module header record, depicted in Figure B-2, is composed of the following fields. The name, symbolic representation, and length of each field are presented, followed by a symbolic value or an explanation of the contents of the field, where appropriate.

The field EMH$W_RECTYP redefines EOBJ$W_RECTYP. It must contain the value EOBJ$C_EMH.

The field EMH$W_SIZE redefines EOBJ$W_SIZE. It is the size of the entire record, including the preceding record type field.

The field EMH$W_HDRTYP redefines EOBJ$W_SUBTYP. It must contain a header subtype such as EMH$C_MHD (main module header) or EMH$C_LNM (language name and version).

The structure level is EOBJ$C_STRLVL, or EOBJ$C_STRLVL64 if any program section definition records require 64-bit address space. Because the format of the MHD record never changes, the structure level field is provided so that changes in the format of other records can be made without recompiling every module that conformed to the previous format.

Alignment, must be zero.

Currently unused, must be zero.

Currently unused, must be zero.

This field contains the size in bytes of the longest record that can occur in the object module. This value may not exceed the maximum size of a record that is defined by the constant EOBJ$C_MAXRECSIZ, which is 8192 bytes.

This field contains the length in bytes of the module name.

This field contains the module name in ASCII format.

This field contains the module version number as an ASCII-counted string. The length byte must be present and contain 0 if there is no module version.

This field contains the module creation time and date in the fixed format dd-mmm-yyyy hh:mm, where dd is the day of the month, mmm is the standard 3-character abbreviation of the month, yyyy is the year, hh is the hour (00 to 23), and mm is the minutes of the hour (00 to 59). Note that a space is required after the year and that the total character count for this time format is 17 characters (including hyphens (-), the space, and the colon (:)).

B.2.2 Language Processor Name Header Record (EMH$C_LNM)

The language processor name header record is composed of the following fields:

EMH$W_RECTYP redefines EOBJ$W_RECTYP. The record type is EOBJ$C_EMH.

The field EMH$W_SIZE redefines EOBJ$W_SIZE. It is the size of the entire record, including the preceding record type field.

EMH$W_HDRTYP redefines EOBJ$W_SUBTYP. The header type is EMH$C_LNM.

This field, which is generated by the language processor, contains the name and version of the compiler that wrote the object module. It consists of a variable-length string of ASCII characters and is not preceded by a byte count of the string.

B.2.3 Source Files Header Record (EMH$C_SRC)

The contents of the source files header record, although ignored by the linker, are displayed in an object module analysis. (See the description of the ANALYZE/OBJECT command in the OpenVMS DCL Dictionary.) The source files header record is composed of the following fields:

EMH$W_RECTYP redefines EOBJ$W_RECTYP. The record type is EOBJ$C_EMH.

The field EMH$W_SIZE redefines EOBJ$W_SIZE. It is the size of the entire record, including the preceding record type field.

EMH$W_HDRTYP redefines EOBJ$W_SUBTYP. The header type is EMH$C_SRC.

This field, which is generated by the compiler, contains the list of file specifications from which the object module was created. It consists of a variable-length string of ASCII characters and is not preceded by a byte count of the string.

B.2.4 Title Text Header Record (EMH$C_TTL)

The contents of the title text header record, although ignored by the linker, are displayed in an object module analysis. (See the description of the ANALYZE/OBJECT command in the OpenVMS DCL Dictionary.) The title text header record is composed of the following fields:

EMH$W_RECTYP redefines EOBJ$W_RECTYP. The record type is EOBJ$C_EMH.

The field EMH$W_SIZE redefines EOBJ$W_SIZE. It is the size of the entire record, including the preceding record type field.

EMH$W_HDRTYP redefines EOBJ$W_SUBTYP. The header type is EMH$C_TTL.

This field, which is generated by the language processor, contains a brief description of the object module. It consists of a variable-length string of ASCII characters and is not preceded by a byte count of the string.

B.3 Global Symbol Directory Records (EOBJ$C_EGSD)

GSD records contain information that the linker uses to build link-time structures describing symbol references, symbol definitions, procedure definitions, and psect definitions. These structures are used to build the global symbol table, the debugger symbol table, and image sections, including the fix-up section.

At least one GSD record must appear in each object module.

A GSD record consists of a type field (EGSD$W_RECTYP), a size field (EGSD$W_RECSIZ), a quadword-alignment field (EGSD$L_ALIGNLW), and one or more GSD subrecords. Each subrecord consists of a type field, a size field, and one or more fields that differ depending on the type value. Each GSD subrecord must start on a quadword boundary. The beginning of the GSD record is filled out to a quadword by the EGSD$L_ALIGNLW field. This places the first subrecord on a quadword boundary. Each subrecord must be filled out to a quadword boundary by padding with zeros so that the following subrecord is also quadword aligned. Any padding must be reflected in the record's total byte count.

Table B-5 lists each type of GSD subrecord together with its symbolic representation and its corresponding numeric value.

A single GSD record must contain at least one of the above types of subrecords. The number of subrecords in a GSD record is limited by the maximum record size specified in the header field EMH$L_RECSIZ. Figure B-1 shows the general format of a GSD record that contains two subrecords. Note that the RECORD TYPE and RECORD SIZE fields appear only once at the beginning of the record, regardless of how many subrecords there are. The RECORD SIZE field counts all of the bytes in the record, including the RECORD TYPE and RECORD SIZE fields themselves, and all of the GSD subrecords. Each GSD subrecord includes a GSD SUBRECORD TYPE and GSD SUBRECORD SIZE field. The RECORD TYPE and RECORD SIZE fields for the GSD record are not listed in the following sections, which describe each subrecord, and are not shown in the diagrams.

B.3.1 Program Section Definition Subrecords (EGSD$C_PSC, EGSD$C_PSC64, EGSD$C_SPSC, EGSD$C_SPSC64)

The linker assigns program sections an identifying index number as it processes each successive psect definition, that is, each EGSD$C_PSC or EGSD$C_PSC64 subrecord. The linker assigns these numbers in sequential order, assigning 0 to the first program section it encounters, 1 to the second, and so on, up to the maximum allowable limit of 65,535 (2¹⁶ --1) within any single object module.

Program sections are referred to by other object language records by means of this program section index. For example, the global symbol specification subrecord (EGSD$C_SYM) contains a field that specifies the program section index. This field is used to locate the program section containing storage for the symbol. Text information and relocation (TIR) commands also use the program section index.

Care is required to ensure that program sections are defined to the linker (and thus assigned an index) in the proper order so that other object language records that reference a program section by means of the index are in fact referencing the correct program section. Program sections may be referenced before they are defined, although it is good practice to define the program sections first when possible.

B.3.1.1 Normal Program Section Definition Subrecord (EGSD$C_PSC, EGSD$C_PSC64)

Figure B-3 depicts the format of a program section definition subrecord, showing the fields it contains and providing a description of each. EGSD$C_PSC64 is the program section definition subrecord for 64-bit sections and has the same format shown in Figure B-3, with the name prefix EGPS64$ rather than EGPS$. EGSD$C_PSC64 differs from EGSD$C_PSC only in that the psect field length, EGPS64$Q_ALLOC, is a quadword rather than a longword. EGSD$C_PSC64 is to be used only if the psect length will not fit in the longword EGPS$L_ALLOC field.

Figure B-3 GSD Subrecord for a Program Section Definition

The GSD type is EGSD$C_PSC.

This field contains the size of the entire subrecord, including the preceding type field and any padding used to quadword-align the following record.

This field specifies the virtual address boundary at which the program section is placed. Each contribution to a particular program section may specify its own alignment. If the contributions have different alignments, the greatest alignment is used to align the entire program section. The flags field of an overlaid program section has the EGPS$V_OVR bit set.

The alignment field contains a value between 0 and 16, which is interpreted as a power of 2; the value of this expression is the alignment in bytes between 1 and 64K. Table B-6 illustrates some common alignment field values.

Field alignment byte. Must be 0.

This field is a word-length bit field, each bit indicating (when set) that the program section has the corresponding attribute. (See Section 3.2 for a description of program section attributes.) The following table lists the numbers, names, and corresponding meanings of each bit in the field:

This field contains the length in bytes of this module's contribution to the program section. If the program section is absolute, the value of the allocation field must be 0. In EGSD$C_PSC64 records, the allocation field EGPS64$Q_ALLOC is 8 bytes in length.

This field contains the length in bytes of the program section name.

This field contains the name of the program section in ASCII format. Note that program section names are limited to 31 bytes, while symbol names are limited to 64 bytes. Compilers that implement global symbols as overlaid program sections (as opposed to global symbol definitions with storage allocated by a concatenated program section) must be aware of this restriction.