Relocatable Object Module Format

From Infogalactic: the planetary knowledge core
Jump to: navigation, search
Relocatable Object Module Format
Filename extension .obj
Developed by Tool Interface Standards Committee
Type of format Object file

The Relocatable 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 under the name Object Module Format, and is perhaps best known to DOS users as an .OBJ file. It has since been standardised by the Tool Interface Standards Committee.

File format

Many object file formats consist of a set of tables, such as the relocation table, which are either stored on fixed positions in the file, like the a.out format, or are pointed to by the header, like the ELF format. The "sections", code, data area, etc., are stored as contiguous area of bytes within such files.

The Relocatable Object Module Format, however, was designed to require minimal memory when linking, and consists of a series of records that have the following format:

Size Contents
1 byte Record type, for example relocation information
2 bytes Data length (N+1)
N bytes Data (varies depending on the record type)
1 byte Checksum or 0

There is a wide variety of record types because of consolidation of OMF variants from several vendors, and adding such features as 32-bit code and dynamic linking, Important record types are:

  • COMENT - (88h) Comment, which despite its name may also contain control information.
  • EXTDEF - (8Ch) Defines external references
  • PUBDEF - (90h/91h) Identifies external symbols in this module
  • SEGDEF - (98h/99h) Identifies segments
  • GRPDEF - (9Ah) Identifies groups of segments, for example MS-DOS DGROUP
  • FIXUPP - (9Ch/9Dh) Fixup or relocation records
  • LEDATA - (A0h/A1h) Contains text of a code or data section
  • COMDEF - (B0h) Uninitialized common data
  • COMDAT - (C2h/C3h) Initialized common data
  • MODEND - (8Ah/8Bh) Indicates end of module

There is no header containing file offsets, such as a pointer to a symbol table, in the file; a linker must completely parse the object file to extract all the information.

In the OMF format the data of one section is not necessarily stored as contiguous bytes in the file, instead it can be represented by multiple records. The file format specification (version 1.1) says that this must be done for sections larger than 1 KiB. Records containing relocation information (fixups) must be stored immediately following the data records of the section they apply to, so the section data and the relocation information is "mixed" in the file.

The file format provides special records (LIDATA) that allow compression of repeating data sequences in an object file. It also provides the possibility to store the symbol name of the entry point of the later executable file in one object file.

The file format can also be used as library file format.

Use

The file format is the most important object file format under MS-DOS, 16-bit Windows and 16-bit and 32-bit OS/2.

Only few tool chains use the 32-bit version of the OMF format. For example, the Watcom C tool chain allows generating code for targets that use 32-bit segmented memory layouts; Iron Spring PL/I can generate code for OS/2 32-bit flat memory layouts.

See also

References

Further reading

External links

  • Lua error in package.lua at line 80: module 'strict' not found.