home *** CD-ROM | disk | FTP | other *** search
/ PC World 2000 February / PCWorld_2000-02_cd.bin / Software / Servis / FFE / MISC.SWG / 0006_OBJ.pas < prev    next >
Pascal/Delphi Source File  |  1996-09-04  |  20KB  |  456 lines
  1. --------B-OBJ-------------------------------
  2.  
  3. Most  of  the description was taken  from  the Microsoft Product Support
  4. Services  Application Note SS0288. The .OBJ  files are binary files used
  5. by  compilers  to  link  in precompiled  code.  They  contain symbol and
  6. relocation  information necessary to link the data and code contained in
  7. the files. The .OBJ files have no common header which makes a validation
  8. or  identification guesswork at best. The .OBJ files consist of at least
  9. one record, each of the following type :
  10.  
  11. OFFSET              Count TYPE   Description
  12. 0000h                   1 byte   Record type (see below)
  13. 0001h                   1 word   Record length
  14.                                  ="LEN"
  15. 0003h               "LEN" byte   Record data
  16. 0003h                   1 byte   Checksum or 0
  17.  +"LEN"                          (that much for validation)
  18.  
  19. The  maximum  size  of  the entire  record  (unless  otherwise noted for
  20. specific record types) is 1024 bytes.
  21.  
  22. For  LINK386,  the format is determined  by the least-significant bit of
  23. the Record Type field. An odd Record Type indicates that certain numeric
  24. fields  within  the  record contain 32-bit  values;  an even Record Type
  25. indicates  that those fields contain  16-bit values. The affected fields
  26. are described with each record. Note that this principle does not govern
  27. the  Use32/Use16  segment  attribute (which is  set  in the ACBP byte of
  28. SEGDEF  records); it simply specifies the size of certain numeric fields
  29. within  the record. It is possible to use 16-bit OMF records to generate
  30. 32-bit segments, or vice versa.
  31.  
  32. LINK  ignores  the value of the  checksum byte, but some other utilities
  33. may not. Microsoft's Quick languages write a 0 byte instead of computing
  34. a checksum.
  35.  
  36. The  contents  of  each record are  determined  by  the record type, but
  37. certain  subfields appear frequently enough  to be explained separately.
  38. The format of such fields is below.
  39.  
  40. Names :
  41.  
  42. A name string is encoded as an 8-bit unsigned count followed by a string
  43. of  count characters. The character set  is usually some ASCII subset. A
  44. null  name  is specified by a single  byte  of 0 (indicating a string of
  45. length 0).
  46.  
  47. Indexed References :
  48.  
  49. Certain items are ordered by occurrence and are referenced by index. The
  50. first  occurrence  of  the  item has  index  number  1. Index fields may
  51. contain  0  (indicating  that  they are  not  present)  or values from 1
  52. through 7FFF. The index number field in an object record can be either 1
  53. or 2 bytes long. If the number is in the range 0-7FH, the high-order bit
  54. (bit  7)  is 0 and the low-order  bits  contain the index number, so the
  55. field  is  only  1 byte long. If the  index  number  is in the range 80-
  56. 7FFFH, the field is 2 bytes long. The
  57.  
  58. Type Indexes :
  59.  
  60. Type  Index  fields  occupy 1 or 2  bytes  and occur in PUBDEF, LPUBDEF,
  61. COMDEF,  LCOMDEF,  EXTDEF,  and  LEXTDEF  records.  They  are encoded as
  62. described  above  for indexed references,  but the interpretation of the
  63. values  stored is governed by whether the  module has the "new" or "old"
  64. object module format.
  65.  
  66. "Old"  versions  of the OMF (indicated by  lack  of a COMENT record with
  67. comment  class  A1),  have Type Index  fields  that contain indexes into
  68. previously  seen  TYPDEF records. This format  is  no longer produced by
  69. Microsoft  products  and  is ignored by LINK  if  it is present. See the
  70. section  of this document on TYPDEF records  for details on how this was
  71. used.
  72.  
  73. "New"  versions of the OMF (indicated by the presence of a COMENT record
  74. with  comment class A1), have Type Index fields that contain proprietary
  75. CodeView information. For more information on CodeView, see Appendix 1.
  76.  
  77. Ordered Collections :
  78.  
  79. Certain records and record groups are ordered so that the records may be
  80. referred  to  with  indexes (the format  of  indexes is described in the
  81. "Indexed  References" section of this document). The same format is used
  82. whether an index refers to names, logical segments, or other items.
  83.  
  84. The  overall  ordering is obtained from  the order of the records within
  85. the  file  together  with the ordering  of  repeated fields within these
  86. records. Such ordered collections are referenced by index, counting from
  87. 1 (index 0 indicates unknown or not specified).
  88.  
  89. For  example, there may be many LNAMES records within a module, and each
  90. of  those records may contain many names. The names are indexed starting
  91. at  1  for the first name in  the  first LNAMES record encountered while
  92. reading  the  file,  2 for the second  name  in the first record, and so
  93. forth,  with  the  highest index for the  last  name  in the last LNAMES
  94. record encountered.
  95.  
  96. The ordered collections are:
  97.  
  98.    Names       Ordered by occurrence of LNAMES records and
  99.                names within each. Referenced as a name
  100.                index.
  101.  
  102.    Logical     Ordered by occurrence of SEGDEF records in
  103.    Segments    file. Referenced as a segment index.
  104.  
  105.    Groups      Ordered by occurrence of GRPDEF records in
  106.                file. Referenced as a group index.
  107.  
  108.    External    Ordered by occurrence of EXTDEF, COMDEF,
  109.    Symbols     LEXTDEF, and LCOMDEF records and symbols
  110.                within each. Referenced as an external name
  111.                index (in FIXUP subrecords).
  112.  
  113.  
  114. Numeric 2- and 4-Byte Fields :
  115.  
  116. Certain  records,  notably  SEGDEF,  PUBDEF,  LPUBDEF,  LINNUM,  LEDATA,
  117. LIDATA,  FIXUPP,  and  MODEND, contain  size,  offset,  and displacement
  118. values that may be 32-bit quantities for Use32 segments. The encoding is
  119. as follows:
  120.  
  121.  - When the least-significant bit of the record type byte is set (that
  122.    is, the record type is an odd number), the numeric fields are 4
  123.    bytes.
  124.  
  125.  - When the least-significant bit of the record type byte is clear,
  126.    the fields occupy 2 bytes. The values are zero-extended when
  127.    applied to Use32 segments.
  128.  
  129.   NOTE: See the description of SEGDEF records in this document for an
  130.   explanation of Use16/Use32 segments.
  131.  
  132.  
  133. The  general  record ordering is not  mandatory, but should be (for link
  134. speed) like this :
  135.  
  136. THEADR or LHEADR record :
  137.  
  138.   Records Processed by LINK Pass 1 :
  139. All  records may occur in any order  but must stand before the link pass
  140. separator, if it is present.
  141.  
  142.    COMENT records identifying object format and extensions
  143.    COMENT records other than Link Pass Separator comment
  144.    LNAMES or LLNAMES records providing ordered name list
  145.    SEGDEF records providing ordered list of program segments
  146.    GRPDEF records providing ordered list of logical segments
  147.    TYPDEF records (obsolete)
  148.    ALIAS records
  149.    PUBDEF records locating and naming public symbols
  150.    LPUBDEF records locating and naming private symbols
  151.    COMDEF, LCOMDEF, EXTDEF, LEXTDEF, and CEXTDEF records
  152.  
  153. Link Pass Separator (Optional) :
  154.  
  155. COMENT class A2 record indicating that Pass 1 of the linker is complete.
  156. When  this record is encountered, LINK  stops reading the object file in
  157. Pass  1;  no  records  after this comment  are  read  in Pass 1. All the
  158. records listed above must come before this COMENT record.
  159.  
  160. For  greater linking speed, all  LIDATA, LEDATA, FIXUPP, BAKPAT, INCDEF,
  161. and  LINNUM records should come after the  A2 COMENT record, but this is
  162. not  required.  In LINK, Pass 2 begins  again at the start of the object
  163. module,  so  these records are processed in  Pass 2 no matter where they
  164. are placed in the object module.
  165.  
  166. Records Ignored by LINK Pass 1 and Processed by LINK Pass 2 :
  167.  
  168. The following records may come before or after the Link Pass
  169. Separator:
  170.  
  171.    LIDATA, LEDATA, or COMDAT records followed by applicable FIXUPP
  172.    records
  173.    FIXUPP records containing only THREAD subrecords
  174.    BAKPAT and NBKPAT FIXUPP records
  175.    COMENT class A0, subrecord type 03 (INCDEF) records containing
  176.    incremental compilation information for FIXUPP and LINNUM records
  177.    LINNUM and LINSYM records providing line number and program code or
  178.    data association
  179.  
  180. Terminator :
  181.  
  182.    MODEND record indicating end of module with optional start address
  183.  
  184. Details  of  each  record  (form  and  content)  follow below. Conflicts
  185. between various OMFs that overlap in their use of record types or fields
  186. are marked.
  187.  
  188. Below  is a combined list of record  types defined by the Intel 8086 OMF
  189. specification  and  record  types  added  after  that  specification was
  190. finished. Titles in square brackets ([]) indicate record types that have
  191. been  implemented and that are described in this document. Titles not in
  192. square brackets indicate record types that have not been implemented and
  193. are followed by a paragraph of description from the Intel specification.
  194.  
  195. For  unimplemented  record types, a  subtle  distinction is made between
  196. records that LINK ignores and those for which LINK generates an "illegal
  197. object format" error condition.
  198.  
  199. Records Currently Defined
  200.  
  201.    6EH     RHEADR   R-Module Header Record
  202.                     This record serves to identify a module that has
  203.                     been processed (output) by LINK-86/LOCATE-86. It
  204.                     also specifies the module attributes and gives
  205.                     information on memory usage and need. This record
  206.                     type is ignored by Microsoft LINK.
  207.  
  208.    70H     REGINT   Register Initialization Record
  209.                     This record provides information about the 8086
  210.                     register/register-pairs: CS and IP, SS and SP, DS
  211.                     and ES. The purpose of this information is for a
  212.                     loader to set the necessary registers for
  213.                     initiation of execution. This record type is
  214.                     ignored by Microsoft LINK.
  215.  
  216.    72H     REDATA   Relocatable Enumerated Data Record
  217.                     This record provides contiguous data from which a
  218.                     portion of an 8086 memory image may eventually be
  219.                     constructed. The data may be loaded directly by
  220.                     an 8086 loader, with perhaps some base fixups.
  221.                     The record may also be called a Load-Time
  222.                     Locatable (LTL) Enumerated Data Record. This
  223.                     record type is ignored by Microsoft LINK.
  224.  
  225.    74H     RIDATA   Relocatable Iterated Data Record
  226.                     This record provides contiguous data from which a
  227.                     portion of an 8086 memory image may eventually be
  228.                     constructed. The data may be loaded directly by
  229.                     an 8086 loader, but data bytes within the record
  230.                     may require expansion. The record may also be
  231.                     called a Load-Time Locatable (LTL) Iterated Data
  232.                     Record. This record type is ignored by Microsoft
  233.                     LINK.
  234.  
  235.    76H     OVLDEF   Overlay Definition Record
  236.                     This record provides the overlay's name, its
  237.                     location in the object file, and its attributes.
  238.                     A loader may use this record to locate the data
  239.                     records of the overlay in the object file. This
  240.                     record type is ignored by Microsoft LINK.
  241.  
  242.    78H     ENDREC   End Record
  243.                     This record is used to denote the end of a set of
  244.                     records, such as a block or an overlay. This
  245.                     record type is ignored by Microsoft LINK.
  246.  
  247.    7AH     BLKDEF   Block Definition Record
  248.                     This record provides information about blocks
  249.                     that were defined in the source program input to
  250.                     the translator that produced the module. A BLKDEF
  251.                     record will be generated for every procedure and
  252.                     for every block that contains variables. This
  253.                     information is used to aid debugging programs.
  254.                     This record type is ignored by Microsoft LINK.
  255.  
  256.    7CH     BLKEND   Block End Record
  257.                     This record, together with the BLKDEF record,
  258.                     provides information about the scope of variables
  259.                     in the source program. Each BLKDEF record must be
  260.                     followed by a BLKEND record. The order of the
  261.                     BLKDEF, debug symbol records, and BLKEND records
  262.                     should reflect the order of declaration in the
  263.                     source module. This record type is ignored by
  264.                     Microsoft LINK.
  265.  
  266.    7EH     DEBSYM   Debug Symbols Record
  267.                     This record provides information about all
  268.                     local symbols, including stack and based symbols.
  269.                     The purpose of this information is to aid debug-
  270.                     ging programs. This record type is ignored by
  271.                     Microsoft LINK.
  272.  
  273.    [80H]   [THEADR] [Translator Header Record]
  274.  
  275.    [82H]   [LHEADR] [Library Module Header Record]
  276.  
  277.    84H     PEDATA   Physical Enumerated Data Record
  278.                     This record provides contiguous data,
  279.                     from which a portion of an 8086 memory
  280.                     image may be constructed. The data
  281.                     belongs to the "unnamed absolute segment"
  282.                     in that it has been assigned absolute
  283.                     8086 memory addresses and has been
  284.                     divorced from all logical segment
  285.                     information. This record type is ignored
  286.                     by Microsoft LINK.
  287.  
  288.    86H     PIDATA   Physical Iterated Data Record
  289.                     This record provides contiguous data,
  290.                     from which a portion of an 8086 memory
  291.                     image may be constructed. It allows
  292.                     initialization of data segments and
  293.                     provides a mechanism to reduce the size
  294.                     of object modules when there is repeated
  295.                     data to be used to initialize a memory
  296.                     image. The data belongs to the "unnamed
  297.                     absolute segment." This record type is
  298.                     ignored by Microsoft LINK.
  299.  
  300.    [88H]   [COMENT] [Comment Record]
  301.  
  302.    [8AH/8BH] [MODEND] [Module End Record]
  303.  
  304.    [8CH]   [EXTDEF] [External Names Definition Record]
  305.  
  306.    [8EH]   [TYPDEF] [Type Definition Record]
  307.  
  308.    [90H/91H] [PUBDEF] [Public Names Definition Record]
  309.  
  310.    92H     LOCSYM   Local Symbols Record
  311.                     This record provides information about
  312.                     symbols that were used in the source
  313.                     program input to the translator that
  314.                     produced the module. This information is
  315.                     used to aid debugging programs. This
  316.                     record has a format identical to the
  317.                     PUBDEF record. This record type is
  318.                     ignored by Microsoft LINK.
  319.  
  320.    [94H/95H] [LINNUM] [Line Numbers Record]
  321.  
  322.    [96H]   [LNAMES] [List of Names Record]
  323.  
  324.    [98H/99H] [SEGDEF] [Segment Definition Record]
  325.  
  326.    [9AH]   [GRPDEF] [Group Definition Record]
  327.  
  328.    [9CH/9DH] [FIXUPP] [Fixup Record]
  329.  
  330.    9EH     (none)   Unnamed record
  331.                     This record number was the only even
  332.                     number not defined by the original Intel
  333.                     specification. Apparently it was never
  334.                     used.  This record type is ignored by
  335.                     Microsoft LINK.
  336.  
  337.    [A0H/A1H] [LEDATA] [Logical Enumerated Data Record]
  338.  
  339.    [A2H/A3H] [LIDATA] [Logical Iterated Data Record]
  340.  
  341.    A4H     LIBHED   Library Header Record
  342.                     This record is the first record in a library
  343.                     file. It immediately precedes the modules
  344.                     (if any) in the library. Following the
  345.                     modules are three more records in the
  346.                     following order: LIBNAM, LIBLOC, and LIBDIC.
  347.                     This record type is ignored by Microsoft
  348.                     LINK.
  349.  
  350.    A6H     LIBNAM   Library Module Names Record
  351.                     This record lists the names of all the
  352.                     modules in the library. The names are listed
  353.                     in the same sequence as the modules appear
  354.                     in the library. This record type is ignored
  355.                     by Microsoft LINK.
  356.  
  357.    A8H     LIBLOC   Library Module Locations Record
  358.                     This record provides the relative location,
  359.                     within the library file, of the first byte
  360.                     of the first record (either a THEADR or
  361.                     LHEADR or RHEADR record) of each module in
  362.                     the library. The order of the locations
  363.                     corresponds to the order of the modules in
  364.                     the library. This record type is ignored by
  365.                     Microsoft LINK.
  366.  
  367.    AAH     LIBDIC   Library Dictionary Record
  368.                     This record gives all the names of public
  369.                     symbols within the library. The public names
  370.                     are separated into groups; all names in the
  371.                     nth group are defined in the nth module of
  372.                     the library. This record type is ignored by
  373.                     Microsoft LINK.
  374.  
  375.    [B0H]   [COMDEF] [Communal Names Definition Record]
  376.  
  377.    [B2H/B3H] [BAKPAT] [Backpatch Record]
  378.  
  379.    [B4H]   [LEXTDEF] [Local External Names Definition Record]
  380.  
  381.    [B6H/B7H] [LPUBDEF] [Local Public Names Definition Record]
  382.  
  383.    [B8H]   [LCOMDEF] [Local Communal Names Definition Record]
  384.  
  385.    BAH/BBH COMFIX   Communal Fixup Record
  386.                     Microsoft doesn't support this never-
  387.                     implemented IBM extension. This record type
  388.                     generates an error when it is encountered by
  389.                     Microsoft LINK.
  390.  
  391.    BCH     CEXTDEF  COMDAT External Names Definition Record
  392.  
  393.    C0H     SELDEF   Selector Definition Record
  394.                     Microsoft doesn't support this never-
  395.                     implemented IBM extension. This record type
  396.                     generates an error when it is encountered by
  397.                     Microsoft LINK.
  398.  
  399.    [C2H/C3] [COMDAT] [Initialized Communal Data Record]
  400.  
  401.    [C4H/C5H] [LINSYM] [Symbol Line Numbers Record]
  402.  
  403.    [C6H]   [ALIAS]  [Alias Definition Record]
  404.  
  405.    [C8H/C9H] [NBKPAT] [Named Backpatch Record]
  406.  
  407.    [CAH]   [LLNAMES] [Local Logical Names Definition Record]
  408.  
  409.    [F0H]            [Library Header Record]
  410.                     Although this is not actually an OMF record
  411.                     type, the presence of a record with F0H as
  412.                     the first byte indicates that the module is
  413.                     a Microsoft library. The format of a library
  414.                     file is given in Appendix 2.
  415.  
  416.    [F1H]            [Library End Record]
  417.  
  418.  
  419. 80H THEADR--TRANSLATOR HEADER RECORD
  420.  
  421. The  THEADR  record  contains the name  of  the object module. This name
  422. identifies  an  object  module within an  object  library or in messages
  423. produced by the linker.
  424.  
  425. OFFSET              Count TYPE   Description
  426. 0000h                   1 byte   ID=80h
  427. 0001h                   1 byte   Record length
  428.                                  ="LEN"
  429. 0002h               "LEN" char   Name
  430. 0002h                   1 byte   Checksum
  431. +"LEN"
  432.  
  433.  
  434. 82H LHEADR--LIBRARY MODULE HEADER RECORD
  435.  
  436. This record is very similar to the THEADR record. It is used to indicate
  437. the  name  of  a  module within a  library  file  (which has an internal
  438. organization  different from that of an object module). This record type
  439. was defined in the original Intel specification with the same format but
  440. with  a different purpose, so its use for libraries should be considered
  441. a Microsoft extension.
  442.  
  443. OFFSET              Count TYPE   Description
  444. 0000h                   1 byte   ID=82h
  445. 0001h                   1 byte   Record length
  446.                                  ="LEN"
  447. 0002h               "LEN" char   Name
  448. 0002h                   1 byte   Checksum
  449. +"LEN"
  450.  
  451. EXTENSION:OBJ,OBP,OBW,LIB
  452. OCCURENCES:PC
  453. PROGRAMS:MS Link, TLink, OBJDUMP
  454. REFERENCE:****
  455.  
  456.