Anobject file is afile that containsmachine code orbytecode, as well as other data andmetadata, generated by acompiler orassembler fromsource code during the compilation or assembly process. The machine code that is generated is known asobject code.
The object code is usuallyrelocatable, and not usually directlyexecutable. There are various formats for object files, and the same machine code can be packaged in different object file formats. An object file may also work like ashared library.
The metadata that object files may include can be used for linking or debugging; it includes information to resolve symbolic cross-references between different modules,relocation information,stack unwinding information,comments, programsymbols, and debugging orprofiling 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.[1]
Alinker is used to combine the object code into one executable program or library pulling in precompiled system libraries as needed.
There are many different object file formats; originally each type of computer and supporting software had its own unique format, such as theOS/360 Object File Format, but with the advent ofUnix and otherportableoperating systems, some formats, such asCOFF,ELF, andMach-O, have been defined and used on different kinds of systems.
Some systems make a distinction between formats which are directly executable and formats which require processing by thelinker. For example,OS/360 and successors call the first format aload module and the second anobject module. In this case the files have entirely different formats.[2]DOS andWindows also have different file formats for executable files and object files, such asPortable Executable for executables and COFF for object files in 32-bit and 64-bit Windows.
Unix andUnix-like systems have used the same format forexecutable and object files, starting with the originala.out format. Some formats can contain machine code for different processors, with the correct one chosen by the operating system when the program is loaded.[3][4]
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 thusprogrammer turnaround while a program is being developed. If the format is used for executables, the design also affects the time programs take tobegin running, and thus theresponsiveness for users.
TheGNU Project'sBinary File Descriptor library (BFD library) provides a commonAPI for the manipulation of object files in a variety of formats.
Many early computers, or smallmicrocomputers, 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 inread-only memory. For example, theMotorola 6800MIKBUG monitor contains a routine to read an absolute object file (SREC Format) frompaper tape.[5]DOSCOM files are a more recent example of absolute object files.[6]
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 ofmemory management. When a program is loaded into memory by aloader, the loader allocates various regions of memory to the program. Some of these regions correspond to sections 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 thememory management unit or byposition-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 donelazily, that is, only when the segments are referenced during execution, for example via amemory-mapped file backed by the object file.
Types of data supported by typical object file formats:[7]
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, inDOS there aredifferent memory models that specify the names of special segments and whether or not they may be combined.[8]
Thedebugging data format of debugging information may either be an integral part of the object file format, as inCOFF, or a semi-independent format which may be used with several object formats, such asstabs orDWARF.