THE ASSEMBLY PROCESS
FROM LIBRARY
7.4 FORMAT OF LIBRARY FILES
A library me is a contiguous me consisting of a header, an Entry Point Table (library directory) and one or more library object modules, as illustrated in Figure 7-1:
LIBRARY HEADER ENTRY POINT TABLE
OBJECT MODULES
LIBRARY END TRAILER BLOCK
Figure 7-1 General Library File Format The following paragraphs describe in detail each component of a library me.
7.4.1 Library Header
The header section of a library me contains 17 (decimal) words which describe the current status of the me (refer to Figure 7 -2). This includes information relating to the version of the Librarian in use, the date and time of me creation or update, the relative starting address of the Entry Point Table (EPT), the number of EPT entries available and in use, and the placing of the next module to be inserted into the library me. The contents of the library header are updated as the library me is modified, so that LIBR can always quickly and easily access the information it needs to perform its functions. Figure 7-2 illustrates the header format.
1 568
7 x 0 x 0 0 0 0 0 128 xl
0 x2 x3 0
}
FORMATTED BINARY BLOCK HEADER'I
1.1
LIBRARIAN CODE VERSION NUMBER RESERVED YEAR-MONTH-DAY
RESERVED
EPT RELATIVE START ADDRESS EPT ENTRIES ALLOCATED IN BYTES EPT ENTRIES AVAILABLE
NEXT INSERT RELATIVE BLOCK NUMBER NEXT BYTE WITHIN BLOCK
NOT USED (MUST BE ZERO)
7.4.2 Entry Point Table (Library Directory)
The Entry Point Table is located immediately after the library header. It is composed of four-word entries which include the names, addresses, and entry points of all object modules in the library file. The first two words of an entry in the EPT contain the Radix 50 name by which an entry point, CSECT, or module is referenced. The third word provides a pointer to the object module where an entry point is defined. The fourth word contains the total number of CSECTs in the object module (information needed by the Linker), and the relative byte within the block pointing to the object module's starting point, as shown in Figure 7 -3.
o
2 4 6
SYMBOL (RAD 50) SYMBOL (RAD 50)
I
ADDRESS OF BLOCK# OF CSECTS IN
I
OBJECT MODULE RELATIVE BYTE IN BLOCK
BIT 15 = 1-MODULE NAME
= 0-CSECT OR ENTRY POINT NAME RELATIVE BYTE MAXIMUM = 7778
CSECTS MAXIMUM = 1778
Figure 7-3 Format of Entry Point Table 7.4.3 Object Modules
Object modules follow the Entry Point Table. An object module consists of three main types of data blocks:
a global symbol directory, text blocks, and a relocation directory. The information contained in these data blocks is used by the Linker during creation of a load module.
7.4.4 Library End Trailer
Following all object modules in a library fIle is a specially coded library end trailer which signifies the end of the file. This trailer is illustrated in Figure 74.
1 FORMATTED BINARY HEADER 10 FORMATTED BINARY LENGTH 10 TYPE CODE
0 NOT USED (MUST BE ZERO)
I
357 CHECKSUM BYTEFigure 74 Library End Trailer 7.5 LIBR ERROR MESSAGES
The following error messages are printed following incorrect use of LIBR; if any errors result during library process-ing, the user must reenter the command.
Message
The user has attempted to build a library fIle containing no directory entries or he has given an illegally constructed library fIle to the Librarian as input.
A bad object module was detected during input.
The user has extended beyond the allowable .CSECT space for an object module to be placed in the library (i.e., the object module contains greater than 127 (decimal) .CSECTS).
The device is full; LIBR is unable to create or update the indicated library fIle. The CSI prints an asterisk and waits for the user to enter another command line.
One of the input fIles indicated in the command line was not found.
The CSI prints an asterisk; the command may be reentered.
An illegal command was used in the command line. The CSI prints an asterisk; the command may be reentered.
An attempt was made to delete from the library's directory a module or an entry point that does not exist; xxxxxx represents the module or entry point name. The name is ignored and processing continues.
An illegal device was specified in the command line. The CSI prints an asterisk; the command may be reentered.
An attempt was made to insert a module into a library which contains the same entry point as an existing module. xxxxxx represents the entry point name. The entry point is ignored but the module is still inserted into the library.
An attempt was made to replace in the library fIle a module which does not already exist. xxxxxx represents the module name. The module is ignored and the library is built without it.
An unrecoverable hardware/software error has occurred while processing an input fIle. The CSI prints an asterisk and waits for another command to be entered.
The user has speCified that a library fIle be replaced by another library fIle. Only object modules can be replaced.
Available free memory has been used up. The current command is aborted and the CSI prints an asterisk; a new command may be entered.
An unrecoverable hardware/software error has occurred while processing an output fIle. This may indicate that there is not enough space left on the device to create the library fIle, even though there may be enough directory entries. The CSI prints an asterisk and waits for the user to enter another command.
ON-LINE DEBUGGING TECHNIQUE
HT-II On-Line Debugging Technique (ODT) is a system program that aids in debugging assembled and linked object programs. From the keyboard, the user interacts with ODT and the object program to:
1. Print the contents of any location for examination or alteration.
2. Run all or any portion of an object program using the breakpoint feature.
3. Search the object program for specific bit patterns.
4. Search the object program for words which reference a specific word.
5. Calculate offsets for relative addresses.
6. Fill a single word, block of words, byte or block of bytes with a designated value.
The assembly listing of the program to be debugged should be readily available when ODT is being used. Minor corrections to the program can be made on-line during the debugging session, and the program may then be run under control of ODT to verify any changes made. Major corrections, however (such as a missing subroutine), should be noted on the assembly listing and incorporated in a subsequent updated program assembly.