In addition to the object code itself, object files may contain metadata
used for linking or debugging, including: information to resolve symbolic cross-references between different modules, relocation
information, stack unwinding
, program symbols
, debugging or profiling
information. Other metadata may include the date and time of compilation, the compiler name and version, and other identifying information.
The term "object program" dates from at least the 1950s:
A term in automatic programming for the machine language program produced by the machine by translating a source program written by the programmer in a language similar to algebraic notation.
A computer programmer generates object code with a compiler
. For example, under Linux
, the GNU Compiler Collection
compiler will generate files with a .o extension which use the ELF
format. Compilation on Windows
generates files with a .obj extension which use the COFF
programs are interpreted
programs are compiled into bytecode
Object file formats
There are many different object file formats; originally each type of computer had its own unique format, but with the advent of Unix
and other portable operating systems
, some formats, such as ELF
, have been defined and used on different kinds of systems. It is possible for the same format to be used both as linker
input and output, and thus as the library
file format.: p.16
Some formats can contain machine code for different processors, with the correct one chosen by the operating system when the program is loaded.
Some systems make a distinction between formats which are directly executable and formats which require processing by the linker. For example, OS/360 and successors
call the first format a load module
and the second an object module
. In this case the files have entirely different formats.
The design and/or choice of an object file format is a key part of overall system design. It affects the performance of the linker and thus programmer
turnaround while a program is being developed. If the format is used for executables, the design also affects the time programs take to begin running
, and thus the responsiveness
Absolute object files
Many early computers, or small microcomputers
, support only an absolute object format. Programs are not relocatable; they need to be assembled or compiled to execute at specific, predefined addresses. The file contains no relocation or linkage information. These files can be loaded into read/write memory, or stored in read-only memory
. For example, the Motorola 6800MIKBUG
monitor contains a routine to read an absolute object file (SREC Format
) from paper tape
. DOS COM files
are a more recent example of absolute object files.
Most object file formats are structured as separate sections of data, each section containing a certain type of data. These sections are known as "segments" due to the term "memory segment
", which was previously a common form of memory management
. When a program is loaded into memory by a loader
, the loader allocates various regions of memory to the program. Some of these regions correspond to segments of the object file, and thus are usually known by the same names. Others, such as the stack, only exist at run time. In some cases, relocation
is done by the loader (or linker) to specify the actual memory addresses. However, for many programs or architectures, relocation is not necessary, due to being handled by the memory management unit
or by position-independent code
. On some systems the segments of the object file can then be copied (paged) into memory and executed, without needing further processing. On these systems, this may be done lazily
, that is, only when the segments are referenced during execution, for example via a memory-mapped file
backed by the object file.
Types of data supported by typical object file formats:
Segments in different object files may be combined by the linker according to rules specified when the segments are defined. Conventions exist for segments shared between object files; for instance, in DOS
there are different memory models
that specify the names of special segments and whether or not they may be combined.
Debugging information may either be an integral part of the object file format, as in COFF
, or a semi-independent format
which may be used with several object formats, such as stabs
- ^ Wrubel, Marshal H. (1959). A primer of programming for digital computers. New York: McGraw-Hill. p. 222. Retrieved July 31, 2020.
- ^ IBM Corporation (1973). IBM OS Linkage Editor and Loader (PDF). Retrieved 2012-08-06.
- ^ "FatELF: Universal Binaries for Linux". Retrieved Aug 2, 2020.
- ^ Wiles, Mike; Felix, Andre. MCM6830L7 MIKBUG/MINIBUG ROM (PDF). Motorola Semiconductor Products, Inc. Retrieved July 31, 2020.
- ^ Godse, D.A.; Godse, A.P. (2008). Microprocessor - I (First ed.). Pune: Technical Publications. pp. 3–15. ISBN 978-81-8431-355-0.
- ^ Mauerer, Wolfgang (2010). Professional Linux Kernel Architecture. John Wiley & Sons. p. Appendix E: The ELF Binary Format. ISBN 978-0-470-34343-2. Retrieved Aug 1, 2020.
- ^ Irvine, Kip R. (1993), Assembly language for the IBM-PC (2nd ed.), New York: Macmillan, ISBN 0-02-359651-1
Last edited on 1 September 2021, at 16:11
Content is available under CC BY-SA 3.0
unless otherwise noted.