GOFF

Last updated

The GOFF (Generalized Object File Format) specification was developed for IBM's MVS operating system to supersede the IBM OS/360 Object File Format to compensate for weaknesses in the older format. [1]

Contents

Background

The original IBM OS/360 Object File Format was developed in 1964 for the new IBM System/360 mainframe computer. The format was also used by makers of plug compatible and workalike mainframes, including the Univac 90/60, 90/70 and 90/80 and Fujitsu B2800. The format was expanded to add symbolic records and expanded information about modules, plus support for procedures and functions with names longer than 8 characters. While this helped, it did not provide for the enhanced information necessary for today's more complicated programming languages and more advanced features such as objects, properties and methods, Unicode support, and virtual methods.

The GOFF object file format was developed by IBM approximately in 1995 as a means to overcome these problems. [2] The earliest mention of this format was in the introductory information about the new High Level Assembler. [3] Note that the OS/360 Object File Format was simply superseded by the GOFF format, it was not deprecated, and is still in use by assemblers and language compilers where the language can withstand the limitations of the older format.

Conventions

This article will use the term "module" to refer to any name or equivalent symbol, which is used to provide an identifier for a piece of code or data external to the scope to which it is referenced. A module may refer to a subroutine, a function, Fortran Common or Block Data, an object or class, a method or property of an object or class, or any other named routine or identifier external to that particular scope referencing the external name.

The terms "assembler" for a program that converts assembly language to machine code, as well as to "assemble" as the process of using one, and to "compile," as the process of using a "compiler," which does the same thing for high-level languages, should, for the purposes of this article. be considered interchangeable; thus where "compile" and "compiler" are used, substitute "assemble" and "assembler" as needed.

Numbers used in this article are expressed as follows: unless specified as hexadecimal (base 16), all numbers used are in decimal (base 10). When necessary to express a number in hexadecimal, the standard mainframe assembler format of using the capital letter X preceding the number, expressing any hexadecimal letters in the number in upper case, and enclosing the number in single quotes, e.g. the number 15deadbeef16 would be expressed as X'15DEADBEEF'.

A "byte" as used in this article, is 8-bits, and unless otherwise specified, a "byte" and a "character" are the same thing; characters in EBCDIC are also 8-bit. When multi-byte character sets (such as Unicode) are used in user programs, they will use two (or more) bytes.

Requirements and restrictions

The format is similar to the OS/360 Object File Format but adds additional information for use in building applications. [4]

The following classes used by the binder may be referenced if needed for compilation purposes:
B_ESDExternal Symbol Dictionary Class
B_TEXTText Class
B_RLDRelocation Dictionary Class
B_SYMInternal Symbol Table Class
B_IDRLLanguage-Translator Identification Data Class
B_PRVPseudo-Register Class
B_IDRUUser-specified Identification Data Class
The following class names are reserved by the binder and are not accessible to user applications:
B_IDRBBinder Data Information
B_IDRZSUPER-Zap Data Information
B_IMPEXPImport-Export Table
B_LITLoading Information Table
B_MAPMapping Data

Size limit

According to the Users Guide for z/OS XL C/C++ User's Guide, "The maximum size of a GOFF object is 1 gigabyte." [6]

Record Types

Similarly to the older OS/360 format, object file records are divided into 6 different record types, some added, some deleted, some altered:

Format

GOFF records may be fixed or variable length; the minimum length when using variable-length records is 56 characters, although most records will be longer than this. Except for module and class names, all characters are in the EBCDIC character set. Unix-based systems must use fixed-length (80-byte) records. Records in fixed-length files that are shorter than the fixed length should be zero-filled. To distinguish GOFF records from the older OS/360 object format (where the first byte of a record is X'02') or from commands that may be present in the file, the first byte of each GOFF record is always the binary value X'03', while commands must start with a character value of at least space (X'40'). The next 2 bytes of a GOFF record indicate the record type, continuation and version of the file format. These first 3 bytes are known as the PTV field.

PTV

The PTV field represents the first 3 bytes of every GOFF record.

PTV Field
ByteBitsValuePurpose
0All03Indicates start of a GOFF record
10-30ESD (External Symbol) record
1TXT (Text) record
2RLD (Relocation) record
3LEN (Length) record
4END (End) record
X'5'-X'E'Reserved
X'F'HDR (Header) record
4-5Reserved
6-700Initial record that is not continued on the next record. This should be the only value used for variable-length GOFF records
01Initial record which is continued on next record
10Continuation record not continued on next record
11Continuation record which is continued on the next record
2All00Version Number of the object file format. All values except X'00' are reserved

HDR

The HDR record is required, and must be the first record.

HDR Record
Byte(s)SizeFieldValuePurpose
0-23PTVX'03F000'Only allowed value; HDR record currently cannot be continued
3-47450Reserved
48-514Architecture LevelBinary 0 or 1GOFF Architecture level; all values except 0 and 1 are reserved
52-532Module Properties SizebinaryLength of Module Properties Field
54-5960Reserved
60-0+Module PropertiesModule Properties List (optional)

ESD

An ESD record gives the public name for a module, a main program, a subroutine, procedure, function, property or method in an object, Fortran Common or alternate entry point. An ESD record for a public name must be present in the file before any reference to that name is made by any other record.

ESD Record
Byte(s)SizeFieldValue (or bits)Purpose
0-23PTVX'030000'ESD record with no continuations
X'030100'ESD record which is continued on next record
31Symbol Type00SD - Section Definition; This is used for the former SD, CM (Common) and PC (Private Code, an SD whose name is blank) values. The "Parent" ESDID value must be 0. This is used to define a main program, a subroutine or function for which the code is part of this file. Also used for Fortran Common.
01ED - External Definition. "Parent" ESDID must be non-zero, and be the value of an SD entry that references this external symbol. If an RLD value refers to a class this entry belongs to, the Class that this element refers to must be specified in the External Name field. This is used to name a called procedure or function.
02LD - Label Definition. "Parent" ESDID must be non-zero, and be the value of an SD entry that defines this symbol within itself. This can be used to create an alias for the module or to expose a portion of it as a separate routine. For example, the run-time library for a particular programming language might have certain features it has to use itself, but which are useful by programs written using that language, and so a feature could be given a label so it can be called directly. For example, there may be a complete mathematics package as a single module, and all of the standard functions (Sine, Cosine, Square Root, etc.) could be named entry points in that module.
03PR - Part Reference or Pseudo Register. Distinguished by Name Space ID field. "Parent" ESDID must be non-zero, and be the value of an SD entry that defines this symbol within itself.
04ER and WX - External Reference / Weak External Reference. Distinguished between by the "Binding Strength" value of the "Attributes" field. WX is used where the foreign routine may be missing. For example, if a calculator program had a fast high-performance math package that was optional, it could be called as a WX, and if it was missing or not available, the program could downgrade to a lesser math package.
4-74ESDIDBinaryESDID identifier starting with 1. Each new ESDID must be exactly 1 higher than the previous entry.
8-114Parent ESDIDbinaryThis is the ESDID of the object that defines this entry, if it is part of another object. It is 0 if it has no parent.
12-1540Reserved
16-194OffsetBinaryAddress of this symbol within its Parent ESDID for LD or ED entries; zero otherwise.
20-2340Reserved
24-274LengthBinaryLength of this item for ED and PR types; zero otherwise. If the actual length value is deferred; this value is set to -1.
28-314Extended Attribute ESDIDBinaryESDID of element that contains extended attribute information for ED and LD types; typically used where DLLs are supported for symbols which are resolved at run time (like virtual methods). Zero otherwise.
32-354Extended Attribute OffsetBinaryAddress where extended attributes can be found for the previous field, used for ED and LD records having extended attributes; zero otherwise.
36-3940Reserved
401Name Space IDIdentifies the name space this belongs to
0Reserved for Program Management Binder
1Normal Name
2Pseudo Register
3Parts (External entries allocated space including items containing initialized static data)
411Flags
Fill PresentBit 00No Fill
1Fill Byte Present (only valid for ED types)
MangledBit 10Symbol is not mangled
1Symbol may be mangled
RenameableBit 20Cannot be renamed (same as 'mapped' flag in XOBJ)
1Symbol can be renamed (Can participate in Language Environment (LE) type renaming)
Removable ClassBit 30(Default) Not Removable
1This Class can optionally be deleted without affecting the program's operation (Only valid for ED types)
Bits 4-6Reserved
Reserve Extra SpaceBit 70No Extra Space Reserved
1Reserve 16 bytes of space at the beginning of the Class (MRG class ED type only)
421Fill ValueValue of Fill byte, if Fill Present flag is set
4310Reserved
44-474Associated DataBinaryUsed for ID of environment or static area for LD items using XLINK
48-514PriorityBinarySort order of PR items
52-5980Reserved
60-6910Behavioral AttributesBehavior Attributes for this item (See Behavior Attributes table below)
70-712Name LengthBinaryLength of this item's name; cannot be zero
72-NameTextName of this item with trailing blanks truncated. Must be at least one character; Private Code consists of a single blank. Name is case sensitive.
REM0Trailer: Unused space if needed for fixed-size records; must be zero filled. Not needed in variable-length records.

Continuation

In the case of fixed-length records where the name requires continuation records, the following is used:

ESD Continuation Record
Byte(s)SizeFieldValuePurpose
0-23PTVX'030200'ESD continuation record with no further continuations
X'030300'ESD continuation record which is continued on next record
3-NameTextThe rest of the name if this record is not continued, or the next 77 bytes of the name if continued.
REM0Remainder for a fixed-length record longer than the data supplied. It contains the trailing bytes if this is the last record for this name and the name is shorter than the record size; must be 0 filled. This field is not present in variable-length records.

Behavior Attributes

Behavioral Attributes Field (bytes 60-69 of ESD record)
OffsetSize (Bytes)BitsFieldValuePurpose
01Addressing PropertiesAddressing mode associated with this external symbol. These values are also used by the AMODE field of the END record.
00AMODE not specified (defaults to AMODE (24))
01AMODE(24)
02AMODE(31)
03AMODE(ANY) (24 or 31)
04AMODE(64)
10AMODE(MIN) (Use the smallest AMODE used by all modules)
11Residence PropertiesExternal Symbol's Associated Residence Mode
00RMODE not specified (defaults to RMODE (24))
01RMODE(24)
03RMODE(31) (Equivalent to RMODE(ANY))
04RMODE(64)
210-3 (4)Text Record StyleStyle of text for this class (ED and PR types only) All text must be the same style
0000Byte-oriented
0001Structured data (Binder Oriented)
0010Structured data (user defined)
4-7 (4)Binding AlgorithmData Binding Method
0000Concatenate all items one after another
0001Merge (all identically named items will be located at the same space, using the largest size specified, and most restrictive alignment). Differently named items will be concatenated. This is the usual practice for CM and PR types.
310-2 (3)Tasking BehaviorIndication whether module is reentrant and/or reusable
000Unspecified
001Neither Reusable nor Reentrant (NON-REUS)
010Serially Reusable (REUS)
011Reentrant (RENT), also implies (REUS)
30Reserved
4Read Only0Not Read Only
1Read Only
5-7 (3)Executable000Not Specified
001Not Executable (Data only)
010Executable (Code or Code and data)
410-1 (2)0Reserved
2-3 (2)Duplicate Symbol SeverityLevel of error a duplicate symbol should raise (PR type records only)
00Binder determines severity
01Minimum 4 (Warning)
10Minimum 8 (Error)
11Reserved
4-7 (4)Binding StrengthWeak references will not search other libraries; Strong references will search other libraries for the symbol. Strong Definitions can be resolved to any reference; this is the default.
0000Strong
0001Weak
510-1 (2)Class Loading BehaviorDetermines whether the elements of a class will be loaded in the case of an Operating System LOAD request is used with respect to an object
00LOAD - Load this class
01DEFERRED LOAD - This class will probably be used and should be loaded
10NOLOAD - Do not load this class
11Reserved
2Common FlagIf 1, treat as "old" CM-type COMMON where multiple references set the size to the largest area being used by any reference. An SD type with the same name will keep the size and text. The only text type supported for this is B_TEXT.
3Direct vs. Indirect Reference0Direct References (for purposes of the Binder)
1For PR type, this is a linkage descriptor; for ER type, this is a reference to an XPLINK linkage descriptor
4-7 (4)Binding Scope0000Unspecified
0001Section scope (“local”)
0010Module scope (“global”)
0011Library scope
0100Import-Export scope
610-1 (2)Reserved
2Linkage TypeFor ER, LD, PD, and PR types
0Standard O/S linkage (default)
1XPLINK Linkage
3-7 (5)AlignmentImplied Alignment of this item
00000Byte
00001Halfword
00010Fullword
00011Doubleword
00100Quadword
001014KB page
All alignments shown are available for ED and PR types except PR cannot use page alignment
7-93Reserved

ADATA records

ADATA ("associated data") records are used to provide additional symbol information about a module. They replaced the older SYM records in the 360 object file format. To create an ADATA record

  • Create an ESD record of type ED for the class name that the records are part of
  • Set all fields in the Behavioral Attributes record to 0 except
    • Class Loading (bits 0-1 of byte 5) is X'10'
    • Binding Algorithm is 0
    • Text Record Style (bits 0-3 of byte 2) is X'0010'
    • Optionally set the Read Only (bit 4 of byte 3) and Not Executable (bits 5-7 of byte 3) values if appropriate
  • Create a TXT record for each ADATA item
    • Element ESDID is the value of the ADATA ED record for that particular ADATA entry
    • Offset is zero
    • Data Length is the length of the ADATA record
    • Data field contains the actual ADATA record itself

ADATA records will be appended to the end of the class in the order they are declared.

Class names assigned to ADATA records are translated by IBM programs by converting the binary value to text and appending it to the name C_ADATA, So an item numbered X'0033' would become the text string C_ADATA0033.

ADATA record types
TYpeDescription
X'0000' - X'7FFF'Translator records (note that some values in the range 0-X'0130' are in use by some IBM language translator products including Assembler, Cobol and PL/I).
X'8000' - X'8FFF'Program Management records
X'9000' - X'DFFF'Reserved
X'E000' - X'EFFF'Reserved for compilers and assemblers not released by IBM.
X'F000' - X'FFFF'Available for User Records. IBM will not use these values.

TXT

TXT records specify the machine code instructions and data to be placed at a specific address location in the module. Note that wherever a "length" must be specified for this record, the length value must include any continuations to this record.

TXT Record
Byte(s)SizeFieldBitsValuePurpose
0-23PTVX'031000'TXT record with no continuations
X'031100'TXT record which is continued on next record
310-3 (4)Reserved
Style4-7 (4)All other values are reserved
0000Byte Oriented Data
0001Structured Data (currently the only structured data supported are the 19-byte IDR fields; see IDR Data Table)
0010Unstructured Data
4-74Element ESDIDBinary numberESDID that the contents of this record belong to
8-114Reserved
12-154OffsetBinary addressAddress within ESDID where this data is to be placed. This should be 0 for structured and unstructured data.
16-194Text field true lengthbinary value: 0 or full size after expansionIf Text Encoding field is 0, this must be 0. Otherwise this field is the full size of the text after decompression or unpacking
20-212Text Encodingbinary value0 if text does not require replication, unpacking, or decoding; nonzero to indicate text must be decoded, unpacked or expanded; see Compression Table
22-232Data Lengthbinary value greater than zeroTotal length of the data on this record in bytes as an unsigned value, and cannot be zero, however, this may be partially incorrect, as noted below in Caution.
24-DataMachine code and/or data to be inserted. If IDR data is included it is subject to special rules and requirements, see IDR Data Table
REMNot present for variable-length records; remainder bytes for fixed record longer than remaining data, and must be binary zeroes

Caution

The data length in bytes 22-23 being an unsigned value may be incorrect. According to comments in the GOFF generator part of the LLVM Compiler suite,

"The maximum number of bytes that can be included in an RLD or TXT record and their continuations is a SIGNED 16 bit int despite what the spec says. The number of bytes we allow ourselves to attach to a card is thus arbitrarily limited to 32K-1 bytes." [7]

Continuation

TXT Continuation Record
Byte(s)SizeFieldBitsValuePurpose
0-23PTVX'031200'Continuation Record with no further continuations
X'031300'Continuation Record which is continued next record
3-Data continued from previous record
REMIf remainder of record is longer than data; zero filled

Compression Table

A compression table is used if bytes 20-21 of the TXT record is nonzero. The R value is used to determine the number of times to repeat the string; the L value indicates the length of the text to be repeated "R" times. This could be used for pre-initializing tables or arrays to blanks or zero or for any other purpose where it is useful to express repeated data as a repeat count and a value.

Compression Table
Byte(s)SizeFieldValuePurpose
If value in bytes 20-21 of this TXT record is 0001
0-12RRepeat Count, an unsigned integer greater than 0Number of times to repeat the string starting in byte 4.
2-32LBinary length, an unsigned integer greater than 0Length of string starting in byte 4
4-StringThe string, of length "L" which is to be repeated "R" times.
All other values for bytes 20-21 are reserved

IDR Data Table

The IDR Table, which is located starting at byte 24 of the TXT record, identifies the compiler or assembler (and its version number) that created this object file.

IDR Field
Byte(s)SizeFieldValuePurpose
01x'00'Reserved
11TypeType of IDR field (note that Primary and Secondary identification refers to the first and second identification fields, respectively, appearing on the END card in the former OS/360 Object Module File Format.)
00Primary Identification; Old IDR format 1
01Secondary Identification; Old IDR format 1
02Extended Identification; IDR format 2
03Primary Identification; IDR format 3
04Secondary Identification; IDR format 3
2-32LengthBinary numberLength of IDR data as unsigned integer greater than zero
4+IDR data according to the specified format in byte 1 of this field; see the appropriate IDR Format table for details

IDR Format 1

Note that unlike most number values stored in a GOFF file, the "version", "release" and "trans_date" values are numbers as text characters instead of binary

Format 1 (old format)
Byte(s)SizeFieldValuePurpose
0-910TranslatorAny textThis value is what the assembler or compiler identifies itself as; IBM calls this the "PID value" or "Program ID value" from IBM's catalog numbers of various programs, e.g. the Cobol Compiler for OS/VS1 is called "IKFCBL00"
10-112Versiontwo digitsThis is the version number of the assembler or compiler, 0 to 99.
12-132Releasetwo digitsThis is the release number subpart of the version number above, also 0 to 99
14-185Trans_DateYYDDD5 text characters indicating the 2-digit year, and the 3-digit day of the year this module was compiled or assembled; years 01-65 are presumed to be in the 21st Century, while year 00 or years greater than 65 are presumed to be in the 20th Century, e.g. 2000 or 1966-1999. The three digit day starts at 001 for January 1; 032 for February 1; 060 is March 1 in standard years and February 29 in leap years; and continuing through 365 for December 31 in standard years and 366 for leap years.

IDR Format 2

Normally compilers and assemblers do not generate this format record, it is typically created by the binder.

Format 2
Byte(s)SizeFieldValuePurpose
0-34DatePacked decimal form YYYYDDDFDate module was assembled or compiled, with the year and day of the year
4-52Data_LengthBinary valueActual length of next field, an unsigned, nonzero value
6-8580IDR_DataFormat of this data has not been disclosed

IDR Format 3

All text in this item are character data; no binary information is used.

Format 3
Byte(s)SizeFieldValuePurpose
0-910TranslatorAny text value the compiler/assembler writer wishes to use to identify itself (see the Translator field in old IDR Format 1 above)
10-112Version00 to 99Version number of the assembler or compiler
12-132Release00 to 99Release number of above version
14=207Compile_DateYYYYDDDYear and day of year the program was compiled or assembled (this would be the same format as the 'Trans Date' field from IDR Format 1 above, except the year is a full 4-digit year).
21-299Compile_TimeHHMMSSTTTHour, minute, second and thousandth of second that the program was compiled or assembled

RLD

RLD records allow a module to show where it references an address that must be relocated, such as references to specific locations in itself, or to external modules.

Relocation Directory
Byte(s)SizeFieldValuePurpose
0-23PTVX'032000'Record is not continued
X'032100'Record continues on next record
31Reserved
4-52LengthBinary NumberSize of relocation data; unsigned and must be greater than zero
6-Relocation_DataThe relocation data; see Relocation Data table
REMNot present on variable-length records; remainder of record where record is longer than data, must be zero-filled

Relocation Data

Relocation Data Item
Byte(s)SizeFieldValuePurpose
0-56FlagsFlags regarding this entry; see Flags table for values
6-72Reserved
8-114R_PointerESDID of module (type ED or ER) to use as the target to relocateThis is the "distant" address, either in the same or a different module, that the program needs resolved. This field is omitted if bit 0 of byte 0 of the Flags field is 1.
12-15[A]4P_PointerESDID of module that requires the address to be relocatedThis is the module that wants its reference to a distant identifier to be altered to the correct value. This field is omitted if bit 1 of byte 0 of the Flags field is 1.
16-19[B]4OffsetLocation within module specified by P_Pointer where the address to be adjusted is to be found.This is the address to be relocated. This field is omitted if bit 2 of byte 0 of the Flags field is 1.
20-23[C]4Reserved
24-27[C]4Reserved

[A] If R_Pointer (bit 0 of byte 0 of Flags field is 1) is omitted, this field starts 4 bytes lower, in bytes 8-11.
[B] If R_Pointer or P_Pointer (bit 1 of byte 0 of Flags field is 1) is omitted, this field starts 4 bytes lower, in bytes 12-15. If both fields are omitted, this field starts 8 bytes lower, in bytes 8-11.
[C] If R_Pointer, P_Pointer, or Offset (bit 2 of byte 0 of Flags field is 1) are omitted, this field starts 4 bytes lower. If any two of them are omitted, this field starts 8 bytes lower. If all of them are omitted, this field starts 12 bytes lower.

To clarify, if a module in a C program named "Basura" was to issue a call to the "exit" function to terminate itself, the R_Pointer address would be the ESDID of the routine "exit" while the P_Pointer would be the ESDID of "Basura". If the address was in the same module (like internal subroutines, or a reference to data within the same module) R_Pointer and P_Pointer would be the same.

Flags

RLD Item Flags
Byte(s)SizeFieldBitsPurpose
01Same_R_ID01 If the R_Pointer value for this entry is the same as the previous item in this record; if so, the R_Pointer value is omitted from this entry.
Same_P_ID11 If the P_Pointer value for this entry is the same as the previous item in this record; if so, the P_Pointer value is omitted from this entry.
Same_Offset21 If the Offset value for this entry is the same as the previous item in this record; if so, the Offset value is omitted from this entry.
3-4Reserved
5Reserved
Offset_length60 to indicate 4 byte length
Addressing mode sensitivity70 No Sensitivity
1 Set the high bits of the address to the same as the R mode addressing mode of the R_Pointer address (applies only to V-type addresses)
11R_Pointer_Indicators0-3Data Type of Second Operand of relocation address
0 - R-address
1 - Offset from start of R-address
2 - R-Length (0 for LD items)
6 - Relative immediate (to allow instructions to address external symbols)
7 - R Constant (nonshared data area)
9 - 20-Bit long displacement address
All other values are reserved
4-7Type of item referring to the value needing to be relocated.
0 - Label, R-ID is restricted to LD
1 - Element, R-ID is restricted to ED
2 - Class, R-ID is restricted to ED; Classes do not have external names so they do not have an ESDID
3 - Part, R-ID is restricted to PR
All other values are reserved
21Action_or_Operation0-6Type of operation to use with second operand (the first operand would be 0) the result is a 32-bit signed value which replaces the first operand
0 - Add second operand to first
1 - Subtract second operand from first
All other values are reserved
Fixup Target Fetch/Store7Indicates whether to use or ignore target value
0 - Use fixup/target field as first operand
1 - Ignore value of target field use fixup value as first operand; if no fixup value, use 0
31Reserved
41Target LengthUnsigned length of target field in bytes
51Reserved

LEN

LEN records are used to declare the length of a module where it was not known at the time the ESD record was created, e.g. for one-pass compilers.

FieldOffsetSizeDescription
PTV0-23Record Type X'033000'
3-53Reserved
Length6-72Length of items following this field; value must be non-zero
Elements8-Element length data; see Elements table below
REMTrailing data to end of record for fixed-length records, must contain binary zeroes; not present for variable-length records.

Elements

A deferred-length element entry cannot be continued or split

FieldOffsetSizeDescription
ESDID0-34ESDID of element this value applies to
4-74Reserved
Length8-114Length of the item referenced

END

END must be the last record for a module. An 'Entry Point' is used when an address other than the beginning of the module is to be used as the start point for its execution. This is used either because the program has non-executable data appearing before the start of the module (very common for older assembly programmers, as older versions of the assembler were much slower to assemble data stored in programs once instructions were specified), or because the module calls an external module first, such as a run-time library to initialize itself.

FieldOffsetSizeBitsDescription
PTV0-23X'034000' - Not-continued
X'034100' - Continued on next record
30-56Reserved
Flags6-72Declarations regarding the presence or absence of an entry point
00 - No entry point given; all other values in this record are invalid
01 - Entry point specified by ESDID
10 - Entry point specified by name
11 - Reserved
AMODE41Addressing Mode value of entry point; the values are as specified in field 0 of the Behavior Attributes table in the ESD record.
5-73Reserved
Record Count8-114Number of GOFF records in this module (this is the number of "logical" records, i.e. not counting continuations)
ESDID12-154Value of ESDID if entry point is referenced by ESDID; binary zero if referenced by name
16-194Reserved
Offset20-234Address offset of module entry point; this cannot be specified for an external (ER) entry point
Name Length24-252Length of name, this must be zero if entry point was specified by ESDID.
Name26-The name of the external symbol used as the entry point for this module; is binary zeros if entry point was specified by ESDID; if this record is continued this is the initial 54 characters of the name. This is the only non-binary value in the record; it would be a text field representing the public name for the entry point
REMTrailer extending to the end of the record; should be binary zeros to end of record for fixed-length records; omitted for variable-length

Continuation

If an entry-point name specified on a fixed-length END record is longer than 54 bytes or (if this record itself is also continued) is longer than an additional 77 bytes), the following continuation record is used.

FieldOffsetSizeDescription
PTV0-23X'034200' - This continuation record is not-continued
X'034300' - This continuation record is itself continued on the next record
Name3-The remaining part of the entry-point name, unless this record is continued, in which case it is the next 77 characters of the name.
REMIf this record is not continued, this is the trailing part of the record for fixed-length records and should be binary zeroes; not present for variable-length records

Related Research Articles

Pascal is an imperative and procedural programming language, designed by Niklaus Wirth as a small, efficient language intended to encourage good programming practices using structured programming and data structuring. It is named after French mathematician, philosopher and physicist Blaise Pascal.

<span class="mw-page-title-main">Transaction Processing Facility</span> IBM real-time operating system

Transaction Processing Facility (TPF) is an IBM real-time operating system for mainframe computers descended from the IBM System/360 family, including zSeries and System z9.

In computing, tar is a computer software utility for collecting many files into one archive file, often referred to as a tarball, for distribution or backup purposes. The name is derived from "tape archive", as it was originally developed to write data to sequential I/O devices with no file system of their own, such as devices that use magnetic tape. The archive data sets created by tar contain various file system parameters, such as name, timestamps, ownership, file-access permissions, and directory organization. POSIX abandoned tar in favor of pax, yet tar sees continued widespread use.

<span class="mw-page-title-main">C syntax</span> Set of rules defining correctly structured programs

The syntax of the C programming language is the set of rules governing writing of software in C. It is designed to allow for programs that are extremely terse, have a close relationship with the resulting object code, and yet provide relatively high-level data abstraction. C was the first widely successful high-level language for portable operating-system development.

In computer systems a loader is the part of an operating system that is responsible for loading programs and libraries. It is one of the essential stages in the process of starting a program, as it places programs into memory and prepares them for execution. Loading a program involves either memory-mapping or copying the contents of the executable file containing the program instructions into memory, and then carrying out other required preparatory tasks to prepare the executable for running. Once loading is complete, the operating system starts the program by passing control to the loaded program code.

Mach-O, short for Mach object file format, is a file format for executables, object code, shared libraries, dynamically loaded code, and core dumps. It was developed to replace the a.out format.

A Java class file is a file containing Java bytecode that can be executed on the Java Virtual Machine (JVM). A Java class file is usually produced by a Java compiler from Java programming language source files containing Java classes. If a source file has more than one class, each class is compiled into a separate class file. Thus, it is called a .class file because it contains the bytecode for a single class.

Relocation is the process of assigning load addresses for position-dependent code and data of a program and adjusting the code and data to reflect the assigned addresses. Prior to the advent of multiprocess systems, and still in many embedded systems, the addresses for objects are absolute starting at a known location, often zero. Since multiprocessing systems dynamically link and switch between programs it became necessary to be able to relocate objects using position-independent code. A linker usually performs relocation in conjunction with symbol resolution, the process of searching files and libraries to replace symbolic references or names of libraries with actual usable addresses in memory before running a program.

IP Pascal is an implementation of the Pascal programming language using the IP portability platform, a multiple machine, operating system and language implementation system. It implements the language "Pascaline", and has passed the Pascal Validation Suite.

In computer programming, the block starting symbol is the portion of an object file, executable, or assembly language code that contains statically allocated variables that are declared but have not been assigned a value yet. It is often referred to as the "bss section" or "bss segment".

Intel hexadecimal object file format, Intel hex format or Intellec Hex is a file format that conveys binary information in ASCII text form, making it possible to store on non-binary media such as paper tape, punch cards, etc., to display on text terminals or be printed on line-oriented printers. The format is commonly used for programming microcontrollers, EPROMs, and other types of programmable logic devices and hardware emulators. In a typical application, a compiler or assembler converts a program's source code to machine code and outputs it into a object or executable file in hexadecimal format. In some applications, the Intel hex format is also used as a container format holding packets of stream data. Common file extensions used for the resulting files are .HEX or .H86. The HEX file is then read by a programmer to write the machine code into a PROM or is transferred to the target system for loading and execution. There are various tools to convert files between hexadecimal and binary format, and vice versa.

sizeof is a unary operator in the programming languages C and C++. It generates the storage size of an expression or a data type, measured in the number of char-sized units. Consequently, the construct sizeof (char) is guaranteed to be 1. The actual number of bits of type char is specified by the preprocessor macro CHAR_BIT, defined in the standard include file limits.h. On most modern computing platforms this is eight bits. The result of sizeof has an unsigned integer type that is usually denoted by size_t.

Program database (PDB) is a file format for storing debugging information about a program. PDB files commonly have a .pdb extension. A PDB file is typically created from source files during compilation. It stores a list of all symbols in a module with their addresses and possibly the name of the file and the line on which the symbol was declared. This symbol information is not stored in the module itself, because it takes up a lot of space.

This is an overview of Fortran 95 language features. Included are the additional features of TR-15581:Enhanced Data Type Facilities, which have been universally implemented. Old features that have been superseded by new ones are not described – few of those historic features are used in modern programs although most have been retained in the language to maintain backward compatibility. The current standard is Fortran 2023; many of its new features are still being implemented in compilers.

<span class="mw-page-title-main">SREC (file format)</span> File format developed by Motorola

Motorola S-record is a file format, created by Motorola in the mid-1970s, that conveys binary information as hex values in ASCII text form. This file format may also be known as SRECORD, SREC, S19, S28, S37. It is commonly used for programming flash memory in microcontrollers, EPROMs, EEPROMs, and other types of programmable logic devices. In a typical application, a compiler or assembler converts a program's source code to machine code and outputs it into a HEX file. The HEX file is then imported by a programmer to "burn" the machine code into non-volatile memory, or is transferred to the target system for loading and execution.

The Object Module Format (OMF) is an object file format used primarily for software intended to run on Intel 80x86 microprocessors. It was originally developed by Intel around 1975–1977 for ISIS-II, targeting the 8-bit 8080/8085 processors. This variant later became known as OMF-80. As OMF-86 it was adapted to the 16-bit 8086 processor in 1978.

A debug symbol is a special kind of symbol that attaches additional information to the symbol table of an object file, such as a shared library or an executable. This information allows a symbolic debugger to gain access to information from the source code of the binary, such as the names of identifiers, including variables and routines.

In IBM System/360 through present day z/Architecture, an address constant or "adcon" is an assembly language data type which contains the address of a location in computer memory. An address constant can be one, two, three or four bytes long, although an adcon of less than four bytes is conventionally used to hold an expression for a small integer such as a length, a relative address, or an index value, and does not represent an address at all. Address constants are defined using an assembler language "DC" statement.

The OS/360 Object File Format is the standard object module file format for the IBM DOS/360, OS/360 and VM/370, Univac VS/9, and Fujitsu BS2000 mainframe operating systems. In the 1990s, the format was given an extension with the XSD-type record for the MVS Operating System to support longer module names in the C Programming Language. This format is still in use by the z/VSE operating system. In contrast, it has been superseded by the GOFF file format on the MVS Operating System and on the z/VM Operating System. Since the MVS and z/VM loaders will still handle this older format, some compilers have chosen to continue to produce this format instead of the newer GOFF format.

The FAT file system is a file system used on MS-DOS and Windows 9x family of operating systems. It continues to be used on mobile devices and embedded systems, and thus is a well suited file system for data exchange between computers and devices of almost any type and age from 1981 through the present.

References

  1. John R. Ehrman (March 1, 2001). "How the Linkage Editor Works: A Tutorial on Object/Load Modules, Link Editors, Loaders, and What They Do for (and to) You" (PDF). IBM Silicon Valley (Santa Teresa) Laboratory, San Jose. Retrieved September 8, 2019.[ permanent dead link ]
  2. OS/MVS Program Management: Advanced Facilities (PDF) (eighth ed.). Poughkeepsie, NY: IBM. September 2007. SA22-7644-07. Archived from the original (PDF) on October 19, 2021. Retrieved August 9, 2013.
  3. IBM High Level Assembler for MVS & VM & VSE Release 2 Presentation Guide (PDF). December 1995. SG24-3910-01. Archived from the original (PDF) on 2016-01-23. Retrieved November 13, 2015.
  4. High Level Assembler for z/OS & z/VM & z/VSE Programmer's Guide (PDF) (sixth ed.). San Jose, CA: IBM. July 2008. Appendix C. SC26-4941-05. Retrieved September 8, 2019.[ permanent dead link ]
  5. "RLD". www.ibm.com. IBM. 16 August 2013. Retrieved 10 July 2020.
  6. "Lp64 | Ilp32". IBM .
  7. "llvm/BinaryFormat/GOFF.h - GOFF definitions". LLVM.ORG. Retrieved August 16, 2024.