Files
2024-02-19 00:25:23 -05:00

274 lines
8.7 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
:gdoc sec='Copyright IBM Corp. 1991'.
:prolog.
:docprof
ldrdots='yes'
duplex='no'.
:title.
:tline.IBM OS/2 32 bit Object Module Format (OMF)
:tline.and Linear eXecutable Module Format (LX)
:tline.&rbl.
:tline.Draft 5
:etitle.
.*
:date.
.*
.*
:address.
:aline.Boca Programming Center
:aline.Boca Raton, Florida
:eaddress
:date.
:eprolog.
:frontm.
:tipage.
:lblbox.Purpose of this document
:p.
THIS DOCUMENT PROVIDED BY IBM SHALL BE PROVIDED ON AN "AS IS" BASIS
WITHOUT ANY WARRANTY OF ANY KIND EITHER EXPRESS OR IMPLIED.
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE EXPRESSLY DISCLAIMED.
:p.
FURTHERMORE, THIS DOCUMENTATION IS IN A PRELIMINARY FORM; IS NOT
COMPLETE; HAS NOT YET BEEN TESTED, VALIDATED OR REVIEWED; MAY CONTAIN
ERRORS, OMISSIONS, INACCURACIES OR THE LIKE; AND IS SUBJECT TO BEING
CHANGED, REVISED OR SUPERSEDED IN WHOLE OR IN PART BY IBM.
IBM DOES NOT ASSUME ANY RESPONSIBILITY TO NOTIFY ANY PARTIES, COMPANIES,
USERS, AND OR OTHERS OF DEFECTS, DEFICIENCIES, CHANGES, ERRORS OR OTHER
FAILINGS OR SHORTCOMING OF THE DOCUMENTATION.
:p.
RECIPIENT'S USE OF THIS DOCUMENT IS LIMITED TO RECIPIENT'S PERSONAL USE
FOR THE SOLE PURPOSE OF CREATING TOOLS FOR THE OS/2:fnref refid=ibm.
OPERATING SYSTEM.
:elblbox
:fn id=ibm.
OS/2 is a Registered Trademark of International Business Machines Corp.
:efn.
:toc.
:figlist.
:revision id=r1 char='|' run=yes
:revision id=r2 char='X' run=yes
:revision id=r3 char='B' run=yes
:revision id=r4 char='D' run=yes
.* :rev refid=r1.
.* :p.This line is marked for revision.
.* :erev refid=r1.
:body.
:lblbox.Major changes to this document
:ul
:rev refid=r1.
:li.Draft 1 = Combined information from several documents into one.
:li.Draft 2 = Added Comments from Lexington and Toronto.
:li.Draft 3 = Added the Linear Executable format (LX).
:eul
:elblbox
:erev refid=r1.
:h1.Introduction
:p.This document is intended to describe the interface that is
used by language translators and generators as their intermediate
:rev refid=r1.
output to the linker for the 32-bit OS/2 operating system.
:erev refid=r1.
The linker will generate the executable module that is used by
the loader to invoke the .EXE and .DLL programs at execution time.
:h1.THE 32-BIT OBJECT MODULE FORMAT
:fig place=inline.
:cgraphic.
Record Format:
All object records conform to the following format:
1 byte 2 byte
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>---
<20>Record <20> Record <20>
<20>Type <20> Length <20>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>---
<------ record length in bytes -------->
<variable length> 1 byte
--<2D><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ
<20> Record <20>Chk Sum<75>
<20> Contents <20>or 0 <20>
--<2D><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
:ecgraphic
:figcap.Standard object module record format
:figdesc.
:p.The Record type field is a 1-byte field containing the
hexadecimal number that identifies the type of object record.
The format is determined by the least significant bit of the
RecTyp field.
Note that this does not govern Use32/Use16
segment attributes; it simply specifies the size of certain numeric
fields within the record.
An odd RecTyp indicates that 32-bit
values are present; the fields affected are described with each
record.
:p.
:rev refid=r1.
An entire record occupies RecLength + 3 bytes.
:erev refid=r1.
The record length does not include the count for the record type and
record length fields.
Unless otherwise noted within the record definition, the record length
should not exceed 1024 bytes.
:p.
The byte sum over the entire record, ignoring overflow, is zero.
:p.
The record contents are determined by the record type.
:efig.
:h2.Frequent Object Record Subfields
:p.
Certain subfields appear frequently; the format of such fields is
described next.
:p.
:h3.Names
:p.Name strings are encoded as an 8-bit unsigned count followed by a
string of &odq.count&cdq. characters. The character set is usually
some ASCII subset. A null name is specified by a single byte
of 0 (indicating a string of length zero).
:p.
:h3.Indexed References
:p.Certain items are ordered by occurrence, and referenced by index
(starting index is 1). Index fields can contain 0, indicating
not-present, or values from 1 through 7FFF. The index is encoded
as 1 or 2 bytes and a 16-bit value is obtained as follows&colon.
.fo off
.in +10
if (first_byte & 0x80)
index_word = (first_byte & 7F) * 0x100 + second_byte;
else
index_word = first_byte
.in -10
.fo on
:p.
:h4.Type indices
:p.
The type index is treated as an index field when a record is parsed
(occupies one or two bytes, occurs in PUBDEF, COMDEF,
EXTDEF records).
They are encoded as described under indexed references.
:p.
NOTE&colon. At present, no type checking is done by the linker.
If any link-time semantics are defined, that information will
be recorded somewhere within this document.
:p.
:h4.Ordered Collections
:p.
Certain records and record groups are ordered; the ordering is
obtained from the order of the record types within the file together
with the ordering of repeated fields within these records.
Such ordered collections are referenced by index, counting from 1
(index 0 indicates unknown or decline-to-state).
:p.The ordered collections are&colon.
:ul.
:li.NAMES: ordered by LNAMES record and names within each.
Referenced as a Name Index.
:li.LOGICAL SEGMENTS: ordered by SEGDEF records in file.
Referenced as a Segment Index.
:li.GROUPS: ordered by GRPDEF of records in file.
Referenced as a Group Index.
:rev refid=r1.
:li.External symbols: ordered by EXTDEF and COMDEF
:erev refid=r1.
records and symbols within each.
Referenced as an External Index (in FIXUPs).
:eul.
:p.
:h3.Numeric 2 and 4 byte fields
:p.Words and double words (16 and 32 bit quantities) are stored
in Intel byte order (lowest address is least significant).
:p.Certain records, notably SEGDEF, PUBDEF, LINNUM, LEDATA,
LIDATA, FIXUPP and MODEND, contain size, offset, and
displacement values which may be 32 bit quantities for Use32 segments.
The encoding is as follows.
:ul.
:li.When the least significant bit of the record type byte is
set (ie record type is an odd number), the numeric fields are 4 bytes.
:li.When the least significant bit of the record type byte is
clear, the fields occupy 2 bytes (16 bit Object Module Format).
The values are zero-extended when applied to Use32 segments.
:eul.
:p.See the description of SEGDEF records for an explanation of
Use16/Use32 segments.
.***************
:h2.Order of records
:p.
The record order is chosen so that bind/link passes through an object
module are minimized. This differs from the previous
less specific ordering in that all symbolic information (in particular,
all export and public symbols) must occur at the start of the object
module.
This order is recommended but not mandatory.
.cp 1i
:ol.
:lp.:hp1.Identifier record(s)&colon.:ehp1.
:li.:hp2.Must be the first record.:ehp2.
:rev refid=r1.
:li.THEADR
:erev refid=r1.
.sk
:lp.:hp1.Records processed by Link Pass one&colon.:ehp1.
:li.:hp2.May occur in any order but must precede the Link pass separator
if it is present.:ehp2.
:li.COMENT identifying object format and extensions
:li.COMENT any, other than link pass separator comment.
:li.LNAMES providing ordered name list
:li.SEGDEF providing ordered list of program segments
:li.GRPDEF providing ordered list of logical segments
:li.PUBDEF locating and naming public symbols
:li.COMDEF and EXTDEF records.
:ul.
:li.This group of records is indexed together, so External Index fields
in FIXUPP records may refer to any of the record types listed.
:eul.
.sk
:lp.:hp1.Link pass separator (optional)&colon.:ehp1.
:li.COMENT class A2 indicating that pass 1 of the linker is complete.
When this record is encountered, LINK immediately starts Pass 2; no
records after this comment are read in Pass 1.
All the above listed records must come before this comment record.
:p.For greater linking speed, all LIDATA, LEDATA, FIXUPP and
LINNUM records should come after the A2 comment record, but this is
not required.
In LINK, Pass 2 begins again at the start of the object module, so
LIDATA records, etc., are processed in Pass 2 no matter where they
are placed in the object module.
.sk
:lp.:hp1.Records ignored by link pass one and processed by link pass
two&colon.:ehp1.
:li.LIDATA, LEDATA or COMDAT records followed by applicable FIXUPP records.
:li.FIXUPPs containing THREADs only.
:li.LINNUM providing line number to program code
or data association.
.br
:lp.:hp1.Terminator:ehp1.
:li.MODEND indicating end of module with optional start address.
:eol.
.********************
.** embedded record types in type sequence
.im theadr
.im coment
.im modend
.im extdef
.im pubdef
.im linnum
.im lnames
.im segdef
.im grpdef
.im fixupp
.im ledata
.im lidata
.im comdef
.im comdat
.im exe1
.im exe2
.im exe3
.pa
.pa
:egdoc.