Community hub
0 subscribers7 pages, 0 posts
Recent from talks
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Object code.
Nothing was collected or created yet.
Object code
View on Wikipediafrom Wikipedia
| Program execution |
|---|
| General concepts |
| Types of code |
| Compilation strategies |
| Notable runtimes |
|
| Notable compilers & toolchains |
|
In computing, object code or object module is the product of an assembler or compiler.[1]
In a general sense, object code is a sequence of statements or instructions in a computer language,[2] usually a machine code language (i.e., binary) or an intermediate language such as register transfer language (RTL). The term indicates that the code is the goal or result of the compiling process, with some early sources referring to source code as a "subject program".[3]
Details
[edit]Object files can in turn be linked to form an executable file or library file. In order to be used, object code must either be placed in an executable file, a library file, or an object file.
Object code is a portion of machine code that has not yet been linked into a complete program. It is the machine code for one particular library or module that will make up the completed product. It may also contain placeholders or offsets, not found in the machine code of a completed program, that the linker will use to connect everything together. Whereas machine code is binary code that can be executed directly by the CPU, object code has the jumps and inter-module references partially parametrized so that a linker can fill them in. An object file is assumed to begin at a specific location in memory, often zero. It contains information on instructions that reference memory, so that the linker can relocate the code when combining multiple object files into a single program.
An assembler is used to convert assembly code into machine code (object code). A linker links several object (and library) files to generate an executable. Assemblers (and some compilers) can also assemble directly to machine code to produce executable files without the object intermediary step.[4]
References
[edit]- ^ "Compiler". TechTarget. Archived from the original on 29 April 2012. Retrieved 1 September 2011.
Traditionally, the output of the compilation has been called object code or sometimes an object module.
- ^ Aho, Alfred V.; Sethi, Ravi; Ullman, Jeffrey C. (1986). "10 Code Optimization". Compilers: principles, techniques, and tools. Computer Science. Mark S. Dalton. p. 704. ISBN 0-201-10194-7.
- ^ Luebbert, William F.; Collom jr., Percy (February 1959). "Signal Corps Research and Development on Automatic Programming of Digital Computers". Communications of the ACM. 2 (2): 22–27. Retrieved 20 July 2025.
- ^ Fischer, Charles N. "What do compilers produce?" (PDF). University of Wisconsin Madison. Retrieved 2 April 2024.
Object code
View on Grokipediafrom Grokipedia
Object code is the machine-readable binary code generated by a compiler from human-readable source code, consisting of instructions tailored to a specific computing platform's operating system and hardware architecture.[1] It serves as an intermediate form in the software development process, containing low-level commands that a processor can execute after further processing, but it is not yet a complete, standalone program.[2] Unlike source code, which programmers write in high-level languages for readability and maintainability, object code is platform-specific and opaque to humans, emphasizing efficiency for direct hardware interpretation.[3]
The compilation process transforms source code—such as statements in languages like C or Java—into object code through translation into assembly or bytecode, followed by assembly into binary form.[1] This output typically resides in object files (e.g., with extensions like .o or .obj), which include not only executable instructions but also data sections, relocation information for address adjustments, and symbol tables for resolving external references.[4] Object code conforms to the target processor's Instruction Set Architecture (ISA), such as CISC or RISC, ensuring compatibility but limiting portability across different systems.[1]
To produce a runnable executable, object code undergoes linking, where a linker combines multiple object files and libraries, resolves undefined symbols, and generates relocation directives for loading into memory.[2] Loaders then handle the final placement in main memory, adjusting addresses as needed for execution.[4] This modular approach allows developers to compile code units separately, facilitating large-scale software projects while maintaining modularity and reusability.[4] In interpreted languages like Python or Java, object code may manifest as bytecode, an intermediary that a virtual machine further translates at runtime.[1] Overall, object code represents a critical bridge between high-level programming abstractions and low-level machine operations, underpinning modern software assembly and deployment.[3]
When compiled to object code (e.g., using GCC to produce a relocatable ELF file), it yields binary machine instructions in the
Executing
The compiled object code for this, in an ELF format on a typical x86-64 system, appears as a binary file. A hex dump of the relevant code section might show sequences like
[58]
The equivalent in x86 assembly (which assembles to object code) uses just 7 register-based instructions for efficiency:
[58]
This highlights bytecode's abstraction for portability versus object code's hardware-optimized directness.
Definition and Overview
Definition
Object code is the binary output generated by a compiler from high-level source code or by an assembler from assembly language, consisting of machine-readable instructions and data suitable for a specific target architecture but not yet fully resolved for execution.[5] This intermediate form captures the program's logic in a low-level representation that can be combined with other modules during the linking process to form an executable.[4] Unlike executable code, object code remains in a modular, incomplete state, awaiting resolution of dependencies and address placements.[5] The term "object code" originates from early computing literature of the late 1950s and early 1960s, where the compiler or assembler translates a "subject program" (the input source) into an "object program" (the machine code output).[6] This nomenclature highlighted the transformation process in automatic programming systems, producing a machine-oriented result from human-readable input. Object code is inherently relocatable, featuring unresolved references to external symbols—such as functions or variables defined in other modules—and placeholders for memory addresses that require adjustment based on the final program's layout.[5] These relocation directives enable the linker to patch addresses dynamically, ensuring the code can be loaded into varying memory positions without modification to the instructions themselves.[4] For instance, consider a simple C function that swaps two integers via pointers:c
void swap(int *xp, int *yp) {
int temp = *xp;
*xp = *yp;
*yp = temp;
}
void swap(int *xp, int *yp) {
int temp = *xp;
*xp = *yp;
*yp = temp;
}
.text section, such as x86-64 opcodes for loading values from memory (e.g., movl (%rdi), %eax) and storing them back, accompanied by relocation entries in the .rela.text section to resolve the pointer offsets and symbol references during linking.[5] This structure allows the function to integrate seamlessly with other object modules while preserving its internal logic.[5]
Key Characteristics
Object code exhibits relocatability, allowing it to be positioned at any memory address during the linking process, facilitated by embedded relocation information that the linker uses to adjust internal addresses accordingly.[7] This property enables flexible placement in the final program's memory layout without requiring recompilation.[8] A core aspect of object code is its modularity, as it encapsulates machine code and data for a single compilation unit or module, promoting independent development and reuse across programs.[9] It includes symbol tables that list defined symbols (such as functions and variables) and flag undefined external references for resolution by the linker, ensuring dependencies are handled at link time.[10] This structure supports large-scale software development by isolating concerns within discrete units.[11] Object code is inherently non-executable, as it lacks a complete program entry point and contains unresolved references to external symbols, leading to runtime errors if attempted to run directly due to invalid jumps or calls.[4] Linking is essential to integrate multiple object files, resolve these dependencies, and produce a self-contained executable.[10] It incorporates essential metadata, including debug symbols for source-level debugging, type information, and section headers that delineate areas such as code (.text) and initialized data (.data), which aid in analysis and optimization without embedding in the final binary.[12] These elements are preserved in object files to support development workflows, though they can be stripped later.[7] In terms of size and optimization, object code files are often larger than the corresponding final executables because they retain relocation entries for unresolved references and module-specific metadata, though optimizations like dead code elimination occur at the individual module level during compilation.[7] Global optimizations across modules happen only during linking, potentially reducing the overall executable size.[10]Generation of Object Code
Compilation from Source Code
The compilation of object code from high-level source code, such as C or C++, involves a multi-phase process managed by a compiler, which transforms human-readable source into machine-relatable binary form while preserving relocatability for later linking.[13] The process begins with lexical analysis, where the compiler scans the source code character by character to identify and group tokens—basic units like keywords, identifiers, operators, and literals—effectively converting the text into a stream of meaningful symbols and discarding whitespace or comments.[14] This phase is crucial for initial error detection, such as invalid characters, and is typically implemented using finite automata for efficiency.[15] Following lexical analysis is syntax analysis or parsing, which checks the token stream against the language's grammar rules to build a parse tree or abstract syntax tree (AST) representing the program's structure.[13] The parser ensures syntactic correctness, reporting errors like mismatched brackets or missing semicolons, and uses techniques such as recursive descent or shift-reduce parsing to construct the hierarchical representation.[14] Next comes semantic analysis, which verifies the meaning and context of the AST by performing type checking, scope resolution, and ensuring compliance with language semantics, such as verifying variable declarations before use or compatible operand types in expressions.[15] This phase detects issues like type mismatches or undeclared identifiers that syntax alone cannot catch.[13] The final major step, code generation, produces the object code by translating the semantically verified AST into target-specific assembly or directly into relocatable machine code, often via an intermediate representation (IR).[14] Compilers like GCC and Clang exemplify this architecture: their front-end handles lexical, syntax, and semantic analysis to generate a language-independent IR—GCC uses its own tree-based IR, while Clang produces LLVM IR—followed by the back-end, which optimizes and emits platform-specific object code.[16] For instance, GCC's front-end parses C source into GIMPLE IR tuples, which the back-end then converts to RTL (Register Transfer Language) before generating object code for architectures like x86 or ARM. Before object code emission, compilers apply module-level optimizations to enhance performance and reduce size, such as inlining small functions to eliminate call overhead and dead code elimination to remove unreachable or unused instructions.[17] These optimizations occur post-semantic analysis on the IR, with GCC's-O1 to -O3 flags enabling progressive levels, including loop unrolling and constant propagation, ensuring the resulting object code is efficient yet relocatable.[17] In a typical workflow on Unix-like systems, compiling a C source file file.c to object code uses the command gcc -c file.c -o file.o, which invokes the front-end and back-end to produce a relocatable .o file in ELF (Executable and Linkable Format), containing sections for code, data, and relocation information.[18]
Throughout these phases, compilers provide error handling via diagnostics that interrupt generation if syntax or semantic issues are found, outputting detailed messages with line numbers, error types (e.g., "undeclared identifier"), and suggestions for fixes to aid developers.[19] For example, Clang emphasizes user-friendly diagnostics with fix-it hints, ensuring issues like type errors are reported precisely before any object code is produced.[16] This diagnostic feedback loop is integral, preventing invalid object code and maintaining program integrity.[20]
Assembly from Low-Level Code
Object code is generated from low-level assembly language through the use of an assembler, which performs a direct translation of mnemonic instructions into corresponding machine opcodes.[21] This process typically involves a one-to-one mapping, where each assembly instruction likeMOV or ADD is converted to its binary opcode equivalent based on the target architecture's instruction set, such as Intel x86. For instance, the mnemonic MOV EAX, 4 maps to the opcode bytes B8 04 00 00 00 in 32-bit mode.
Assemblers commonly employ a two-pass mechanism to handle symbol resolution. In the first pass, the assembler scans the source code to build a symbol table, calculating addresses and sizes for labels and resolving forward references without generating code. The second pass then substitutes resolved addresses and emits the machine code, ensuring accurate addressing for jumps, data references, and external symbols. This approach allows for efficient handling of dependencies without requiring multiple full recompilations.
Directives, or pseudo-instructions, guide the assembler in organizing the output without producing executable code themselves. Common directives include SECTION .data for initialized data, SECTION .bss paired with RESB to reserve uninitialized space, and GLOBAL to declare symbols as externally visible for linking. For example, GLOBAL main exports the main symbol, while EXTERN printf imports an external function, enabling the assembler to generate appropriate relocation entries.
The output of the assembler is an object file containing direct machine code segments, along with metadata such as symbol tables and relocation records for unresolved addresses. Fixups are included for forward references and absolute addressing modes, marking locations where the linker must adjust offsets during the linking phase. This results in relocatable code that can be positioned in memory without modification until final linking.
A practical example involves assembling x86 code using the Netwide Assembler (NASM). Consider the following assembly snippet:
section .data
msg db 'Hello', 0
len equ $ - msg
section .text
global _start
_start:
mov eax, 4 ; Syscall: write
mov ebx, 1 ; Stdout
mov ecx, msg ; Message address (relocatable)
mov edx, len ; Length
int 0x80 ; Interrupt
section .data
msg db 'Hello', 0
len equ $ - msg
section .text
global _start
_start:
mov eax, 4 ; Syscall: write
mov ebx, 1 ; Stdout
mov ecx, msg ; Message address (relocatable)
mov edx, len ; Length
int 0x80 ; Interrupt
nasm -f elf hello.asm -o hello.o produces an ELF object file. The .text section contains opcode bytes such as B8 04 00 00 00 for MOV EAX, 4 and B9 followed by a relocation record for MOV ECX, msg, while the .data section holds the string bytes 48 65 6C 6C 6F 00.
Unlike compilation from high-level source code, which involves semantic analysis, optimization, and intermediate representations, assembly focuses on straightforward translation with minimal or no optimization, processing instructions line-by-line or in passes without high-level abstractions.[22]
Structure and Formats
Components of Object Files
Object files are structured to contain machine code, data, and metadata necessary for linking multiple files into an executable or library. These components are organized to support relocatability, symbol resolution, and debugging, with variations across formats like ELF and COFF but sharing common elements. The primary components include a header for file identification, sections for code and data storage, symbol tables for reference tracking, relocation entries for address adjustments, and supplementary metadata for additional context. The header serves as the entry point to the object file, encoding essential metadata such as magic numbers for format identification, target architecture, file version, and occasionally an entry point address. In ELF, the header includes an identification array (e_ident) that specifies the file class (32-bit or 64-bit), data encoding (endianness), and version, along with fields for machine type and program header offsets. Similarly, in COFF, the file header contains a machine field indicating the target processor and a characteristics field denoting file properties like whether it is executable or relocatable. These elements ensure the linker can validate and process the file correctly.[23][24] Sections, also known as segments in some formats, divide the object file into logical units holding specific content, each with defined sizes, alignments, and attributes to guide memory allocation during linking. Common sections include .text, which stores executable machine code instructions; .data, for initialized global and static variables; .bss, which reserves space for uninitialized globals (typically zero-filled at runtime); and .rodata, containing read-only constants like string literals. For example, in ELF, sections are described by a header table with entries specifying type (e.g., SHT_PROGBITS for code and data), flags (e.g., SHF_ALLOC for loadable sections), and alignment requirements to prevent misalignment faults. In COFF, the section table provides similar details, including virtual size, raw data pointers, and characteristics like IMAGE_SCN_CNT_CODE for code sections or IMAGE_SCN_MEM_WRITE for writable data. Alignments, often powers of two (e.g., 4 or 8 bytes), ensure compatibility with the target architecture's memory access patterns.[23][24] The symbol table maintains a directory of symbols, listing those defined within the object file (e.g., functions or variables) and undefined external references, categorized by type (e.g., object, function) and scope (e.g., local, global). Each entry typically includes the symbol name, value (e.g., offset within a section), section index, and binding information. In ELF, the symbol table section (SHT_SYMTAB) uses structures like Elf64_Sym, linking symbols to sections via indices (e.g., SHN_UNDEF for externals). COFF employs an 18-byte symbol record format with fields for name, value, section number, and storage class (e.g., IMAGE_SYM_CLASS_EXTERNAL for globals). This structure allows the linker to match definitions with uses across object files.[23][24] Relocation entries form tables that specify modifications needed in sections to resolve addresses, such as adding a base offset or computing PC-relative jumps, ensuring the code remains position-independent until linked. Each entry points to a location in a section and describes the adjustment type, often tied to a symbol. In ELF, relocation sections (SHT_REL or SHT_RELA) use records like Elf64_Rela with offset, info (encoding symbol and type, e.g., R_X86_64_PC32 for 32-bit PC-relative), and addend fields. COFF relocations are per-section arrays of 10-byte records, including virtual address, symbol table index, and type (e.g., IMAGE_REL_AMD64_ADDR32 for absolute addresses). These entries are crucial for handling inter-module references without hardcoding addresses.[23][24] Additional metadata encompasses supporting structures like string tables, which store null-terminated names for symbols and sections to save space; debug information, often in the DWARF format providing type descriptions, variable locations, and call frames; and line number mappings that associate machine instructions with source code lines for debugging tools. In ELF, string tables appear as SHT_STRTAB sections (e.g., .strtab), while DWARF data resides in sections like .debug_info and .debug_line, encoding abstract syntax trees for program structure. COFF includes similar string tables post-symbol table and debug sections like .debug for line numbers and symbols. This metadata enhances tool support without affecting runtime execution.[23][24][25]Common Object File Formats
Object file formats standardize the storage of compiled code, symbols, and metadata across different operating systems and architectures, enabling portability in linking and execution processes. Widely adopted formats include ELF for Unix-like systems, COFF/PE for Windows, and Mach-O for Apple platforms, each tailored to specific ecosystems while sharing common goals of supporting relocatable code and dynamic loading.[26][24][27] The Executable and Linkable Format (ELF) serves as the primary object file format in Linux and other Unix-like systems, accommodating relocatable objects, executables, shared libraries, and core dumps. It begins with an ELF header featuring thee_ident array, where the first four bytes—known as magic bytes (0x7F 'E' 'L' 'F')—identify the file, followed by indicators for class (e.g., 32-bit or 64-bit) and data encoding (e.g., little-endian). For executables and shared objects, ELF uses program headers (an array of Elf32_Phdr or Elf64_Phdr structures) to define loadable segments, such as text and data, with fields like p_type (e.g., PT_LOAD for loadable segments), p_offset (file offset), and p_vaddr (virtual address). Section headers detail named sections via sh_type values, including SHT_PROGBITS for program data (e.g., .text code), SHT_SYMTAB for symbol tables, SHT_STRTAB for strings, and SHT_NOBITS for uninitialized data like .bss.[26]
The Common Object File Format (COFF), extended as the Portable Executable (PE) format, is the standard for object files and executables on Windows operating systems. COFF object files consist of a COFF header, optional header (for PE images), section table, and raw data sections, with each section header (40 bytes) specifying name, size, and attributes (e.g., IMAGE_SCN_CNT_CODE for executable code). The .idata section holds import tables for resolving external DLL functions, structured as an Import Directory Table (array of RVA-based entries per DLL) followed by Import Lookup Tables, Hint/Name Tables (with 2-byte hints and ASCII names), and Import Address Tables. The .rsrc section organizes resources like icons and dialogs in a hierarchical tree of Type, Name, and Language directories, each with table entries pointing to data. PE builds on COFF by adding an MS-DOS stub and optional header for enhanced portability across Windows versions.[24][28]
Mach-O, the Mach Object format, is used for object files, executables, and libraries on macOS and iOS, emphasizing modularity with segments and sections aligned to page boundaries (at least 4096 bytes). It supports fat binaries, which encapsulate multiple Mach-O files for different architectures (e.g., x86_64 and ARM) within a single universal binary, allowing seamless execution on varied hardware. The header (mach_header or mach_header_64) specifies magic numbers (e.g., MH_MAGIC_64 for 64-bit files) and CPU types, followed by load commands that describe segments like __TEXT (read-only, containing executable code in __text, constants in __const, literal strings in __cstring, and position-independent stubs in __picsymbol_stub) and __DATA (writable, for variables). This structure facilitates sharing of code segments across processes in frameworks.[27][29]
Historical formats include a.out, the original Unix object file used in early systems like PDP-11, featuring a simple header with magic numbers (e.g., 0407 for non-shared text, 0410 for shared) indicating text size, data size, BSS size, symbol table, and relocation flags, followed by code, data, relocation bits, and optional symbols. The Object Module Format (OMF), prevalent in old DOS environments for 16-bit x86 code, employs a record-based structure with types like THEADR (module name), SEGDEF (segment definition), PUBDEF (public symbols), FIXUPP (relocations), and LEDATA (data blocks), each prefixed by a record type byte, length (2 bytes), contents, and checksum. Microsoft's proprietary OBJ format adheres to COFF specifications for compatibility with Windows toolchains.[30][31][32]
Compilers like GCC adapt output formats to the target platform; for instance, GCC on Linux generates ELF object files (.o), while on Windows via MinGW it produces COFF-based files compatible with PE linking.[33]
Linking and Usage
Role in the Linking Process
Object code plays a central role in the linking process by serving as the primary input to linkers, which combine multiple relocatable object files into a cohesive executable or library. The linker reads these object files, each containing sections of code, data, and symbol tables that include both definitions (e.g., functions or variables implemented in the file) and references (e.g., calls to external symbols). During symbol resolution, the linker merges the symbol tables from all input files, matching each reference to a corresponding definition across the set; this ensures that all external dependencies are resolved, preventing runtime errors from unresolved symbols. If any symbols remain undefined after this phase—such as missing library functions—the linker typically reports an error and halts the process, though options exist to force continuation in some tools.[34][35] Following symbol resolution, the linker performs address assignment and relocation to prepare the code for execution. It selects a base memory address for the program (often configurable, such as 0x400000 for ELF executables), then lays out the sections from all object files into a unified memory image, combining like sections (e.g., text for code, data for initialized variables). Relocation entries in the object files—temporary placeholders for addresses—are then updated with absolute offsets relative to the final layout, adjusting instructions and data references accordingly. This step transforms the position-independent offsets in individual object files into concrete machine addresses suitable for loading into memory.[34][35] The output of this process can be an executable file (e.g., ELF on Unix-like systems or PE on Windows) or a static library archive (e.g., .a for GNU or .lib for MSVC), which bundles object files for later linking. Common linkers include GNU ld, which processes inputs via the Binary File Descriptor (BFD) library to handle various formats, and Microsoft's link.exe, which focuses on COFF-based object files. For example, a basic invocation of GNU ld might beld -o program file1.o file2.o, combining the specified object files into an executable named "program." This modular approach enables separate compilation of source modules into object files, allowing developers to work in parallel on different parts of a project and rebuild only changed components, significantly improving efficiency in large-scale software development.[32][36]
Static and Dynamic Linking
Static linking involves resolving all dependencies from object files and libraries at build time, embedding the necessary code directly into the final executable file. This process uses tools like the GNU archiver (ar) to create static library archives (e.g., .a files on Unix-like systems), which the linker (such as ld) then incorporates fully into the output binary.[37] The resulting executable is self-contained, requiring no external libraries at runtime, which simplifies deployment but increases file size due to duplicated code across applications.[38][39]
In contrast, dynamic linking defers the resolution of dependencies until load time or runtime, connecting the object code to shared libraries (e.g., .so on Linux or .dll on Windows) via dynamic symbol tables present in the object files. The dynamic linker/loader, such as ld.so on Linux, handles this by searching for libraries in standard paths or those specified by environment variables like LD_LIBRARY_PATH, performing relocations and symbol binding as needed.[40][41] This approach supports lazy loading, where only required library portions are loaded initially, promoting code reuse across multiple programs and smaller executable sizes.[42][39]
The processes differ fundamentally in tooling and timing: static linking relies on archive tools like ar to bundle object files into libraries without runtime involvement, while dynamic linking requires the operating system's loader to interpret dynamic sections in the executable format (e.g., ELF on Linux) and resolve symbols on-the-fly.[40] For example, a statically linked binary can run independently without library paths, whereas a dynamically linked one might fail if LD_LIBRARY_PATH does not point to the correct shared libraries, as seen in Linux environments.[40] Security implications arise in dynamic linking, such as DLL hijacking on Windows, where attackers place malicious .dll files in search paths to exploit the loader's order, potentially executing arbitrary code.[43][44]
Trade-offs between the two methods influence their use cases: static linking suits embedded systems or environments needing portability, as it avoids runtime dependencies and potential version conflicts, though it complicates updates to shared code.[39][41] Dynamic linking excels in shared code reuse, enabling centralized updates to libraries across applications, but it introduces overhead from loader operations and risks like the aforementioned hijacking.[42][44]
Comparisons and Relations
With Source Code
Object code represents a compiled form of source code, transformed through the compilation process to a lower level of abstraction suitable for machine execution. Source code is written in high-level languages like C or Java, featuring human-readable elements such as variables, loops, conditionals, and comments that abstract away hardware details.[2] In contrast, object code consists of machine-specific binary instructions and data, organized into sections like code, data, and symbols, without the semantic structure or readability of source code.[45] A primary distinction lies in editability. Source code files are plain text, allowing developers to easily modify logic, fix bugs, or refactor using standard editors or integrated development environments.[3] Object code, however, is in binary format and not directly editable; changes necessitate altering the source code and recompiling to generate a new object file.[2] The purposes of the two also differ markedly. Source code facilitates software development, enabling debugging, testing, collaboration, and maintenance through tools like version control systems.[45] Object code, produced as an intermediate artifact, supports efficient machine processing by providing relocatable instructions ready for linking into executables, and is often distributed to protect intellectual property while allowing performance optimization.[3] Regarding size and verbosity, source code is typically larger and more expansive due to descriptive elements like comments, indentation, and redundant explanatory text that aid human comprehension. Object code is more compact, omitting all non-essential metadata and semantics to minimize storage and improve execution speed.[2] To illustrate, consider this simple C source code snippet that prints numbers from 0 to 4:c
#include <stdio.h>
int main() {
int i;
for (i = 0; i < 5; ++i) {
printf("%d\n", i);
}
return 0;
}
#include <stdio.h>
int main() {
int i;
for (i = 0; i < 5; ++i) {
printf("%d\n", i);
}
return 0;
}
48 89 e5 (for entering the function prologue), b8 00 00 00 00 (for loading constants), and c9 c3 (for epilogue and return), representing the processor instructions without any trace of the original high-level constructs.[2]
With Machine Code and Executables
Object code represents an intermediate form of machine instructions that contains unresolved references to symbols and data, requiring further processing through linking to produce absolute machine code suitable for direct execution. In contrast, machine code in its final form consists of fully resolved, position-independent or absolute instructions that the processor can execute without additional modifications. This unresolved state in object code is managed through relocation entries, which specify locations in the code or data sections where addresses need adjustment based on the final memory layout.[26][46] While object code files cannot be executed independently due to their lack of a defined entry point and incomplete address resolution, executable files incorporate the resolved machine code along with necessary metadata, such as loader headers and program headers, to enable direct loading into memory and execution by the operating system. For instance, an ELF object file (type ET_REL) includes section headers for code, data, and symbols but omits program headers required for loading, whereas an ELF executable (type ET_EXEC) features both, allowing the dynamic linker to map segments into virtual memory addresses. This distinction ensures executables are self-contained for runtime environments, whereas object code serves primarily as input to the linker.[26][47] The evolution from object code to executable involves the linker resolving relocations and combining multiple object files into a single binary containing machine code with fixed addresses. During this process, external symbols are replaced with actual offsets or virtual addresses, transforming tentative machine instructions into definitive ones; for example, a reference likeS + A (symbol value plus addend) in an object file's relocation entry becomes a concrete value B + A in the executable, where B is the resolved base address. In ELF format, object files use section-based organization for flexible linking, while executables employ segment-based program headers to delineate loadable portions, facilitating efficient memory mapping by the OS loader.[26][11]
Object code typically retains comprehensive symbol tables and debugging information to support development workflows, whereas executables are often stripped of these elements to reduce file size and enhance security by obscuring internal structure. The strip utility, part of GNU Binutils, removes symbols from executables while preserving essential relocation data if needed, potentially shrinking binaries by eliminating debug sections that can comprise a significant portion of an unstripped file's size. This practice balances deployability with the retention of symbols in object files for linker use and post-link debugging.[48][49]
To illustrate the difference, consider a simple assembly snippet compiled to an object file versus its linked executable. In the object file, a relocation might appear in a hex dump as an unresolved instruction like E8 00 00 00 00 (x86 call with placeholder offset at bytes 1-4, flagged in the relocation table for adjustment), indicating a pending link to an external function. After linking, the executable resolves this to E8 1A 02 00 00 (call with absolute offset 0x0000021A to the function's address), embedded directly in the code section without separate relocation metadata, ready for execution.[46][26]
With Bytecode and Intermediate Representations
Object code represents a platform-specific, machine-oriented intermediate form generated during the compilation of source code, typically containing relocatable machine instructions tailored to a particular hardware architecture and operating system, such as x86 or ARM. In contrast, bytecode, as seen in systems like the Java Virtual Machine (JVM), is a platform-independent instruction set designed for execution on a virtual machine, enabling portability across diverse hardware and operating systems without recompilation.[50] For instance, Java bytecode stored in .class files can run on any JVM implementation, abstracting away underlying differences in processor architectures.[51] Similarly, the .NET Common Intermediate Language (CIL) serves as portable bytecode for the Common Language Runtime (CLR), allowing code written in languages like C# to execute on multiple platforms via CLR support.[52] A key distinction lies in their execution models: object code is directly executable by the hardware after linking into an executable or library, requiring no runtime interpretation or additional translation for the target platform. Bytecode, however, is typically interpreted by a virtual machine or just-in-time (JIT) compiled into native machine code at runtime, introducing an abstraction layer that trades some initial performance overhead for broader compatibility.[50] In the JVM, for example, bytecode instructions are either interpreted directly or converted via JIT to optimized native code, leveraging runtime profiling for efficiency.[53] This contrasts with object code's immediate hardware execution post-linking, which prioritizes native speed without virtual machine intervention. CIL in .NET follows a similar JIT model, where the CLR compiles bytecode to native code on-the-fly, ensuring portability but potentially incurring startup costs absent in native object code workflows.[54] Intermediate representations (IRs), such as LLVM IR, differ from object code in granularity and persistence; they are typically temporary, in-memory structures used during compilation for optimizations, not stable artifacts intended for linking or distribution.[55] LLVM IR, a typed, static single assignment (SSA)-based form, facilitates cross-platform optimizations before backend code generation but is usually not persisted as a final file format like object code (.o files), which contains resolved machine instructions ready for the linker.[56] While LLVM IR can be saved as bitcode (.bc) or assembly (.ll) for intermediate use, it remains an ephemeral step toward producing platform-specific object code, unlike the durable, linkable nature of object files.[57] Bytecode and IRs excel in use cases demanding cross-platform deployment, such as Java applications running unchanged on Windows, Linux, or macOS via the JVM, or .NET assemblies shared across ecosystems.[50][52] Object code, by prioritizing native performance, suits scenarios like system-level software or performance-critical binaries where direct hardware access minimizes overhead, as in C/C++ compilations to executables. To illustrate, consider a simple loop summing integers from 1 to 10. In JVM bytecode, it requires 13 stack-based instructions, including multiple loads and stores to emulate registers:0: iconst_0
1: istore_1
2: iconst_1
3: istore_2
4: iload_2
5: bipush 10
7: if_icmpgt 20
10: iload_1
11: iload_2
12: iadd
13: istore_1
14: iinc 2, 1
17: goto 4
20: getstatic #7
23: iload_1
24: invokevirtual #13
27: return
0: iconst_0
1: istore_1
2: iconst_1
3: istore_2
4: iload_2
5: bipush 10
7: if_icmpgt 20
10: iload_1
11: iload_2
12: iadd
13: istore_1
14: iinc 2, 1
17: goto 4
20: getstatic #7
23: iload_1
24: invokevirtual #13
27: return
mov eax, 1 ; i = 1
mov ecx, 10 ; limit = 10
xor edx, edx ; sum = 0
L: add edx, eax ; sum += i
inc eax ; i++
dec ecx ; limit--
jnz L ; if limit != 0, loop
; Output sum (omitted for brevity)
mov eax, 1 ; i = 1
mov ecx, 10 ; limit = 10
xor edx, edx ; sum = 0
L: add edx, eax ; sum += i
inc eax ; i++
dec ecx ; limit--
jnz L ; if limit != 0, loop
; Output sum (omitted for brevity)