64:{"json":{"id":"seed_97c086d19c515a628efd8dc68c8476f1","slug":"linkers-and-loaders","category":"Operating Systems","topic":"Memory Management Fundamentals","title":"Linkers and Loaders","description":"Master the complete journey from source code to executing process. Explore compilation, object file formats, static and dynamic linking, the loading process, and relocatable code—understanding the critical bridge between programs and memory.","difficulty":"INTERMEDIATE","estimatedMinutes":90,"pages":[{"id":"seed_3a45870b190736448f89970c53fc9028","title":"Compilation Process","order":0,"content":[{"id":"opening-hook","title":"From Human Thought to Machine Execution","content":[{"data":{"content":"Every line of code you write exists in a form that CPUs cannot directly understand. Processors speak the language of binary instructions—sequences of zeros and ones representing operations on registers and memory. The **compilation process** is the elaborate transformation that bridges human-readable source code and machine-executable binaries.\n\nThis transformation is not a simple translation. It involves **multiple sophisticated stages**, each performing specific analyses and transformations that progressively convert high-level abstractions into low-level machine code. Understanding this process is fundamental to operating systems because it directly determines how programs are organized in memory, how they reference code and data, and how the operating system ultimately loads and executes them."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the complete compilation pipeline—preprocessing, compilation proper, assembly, and assembly into object code. You'll grasp how each stage contributes to the final executable, why each stage exists, and how this knowledge impacts memory management and linking.","variant":"info"},"type":"callout"}]},{"id":"big-picture","title":"The Big Picture: Source to Execution","content":[{"data":{"content":"Before examining each stage in detail, let's establish the complete picture. When you invoke a compiler like `gcc` or `clang` on a C source file, it doesn't directly produce an executable. Instead, the compilation system executes **four distinct phases**:\n\n1. **Preprocessing** — Textual manipulation (macro expansion, file inclusion)\n2. **Compilation** — Translation to assembly language\n3. **Assembly** — Conversion to machine code (object file)\n4. **Linking** — Combining object files into an executable\n\nThis modular design is intentional. Each phase has a well-defined input and output, enabling tools to be developed independently and allowing developers to inspect intermediate results for debugging or optimization."},"type":"text"},{"data":{"rows":[["**Preprocessing**","Source code (`.c`, `.cpp`)","Preprocessed source (`.i`)","`cpp` (C Preprocessor)","Macro expansion, includes, conditional compilation"],["**Compilation**","Preprocessed source (`.i`)","Assembly (`.s`)","`cc1` (Compiler proper)","Syntax analysis, optimization, code generation"],["**Assembly**","Assembly (`.s`)","Object code (`.o`)","`as` (Assembler)","Convert mnemonics to machine code"],["**Linking**","Object files (`.o`)","Executable","`ld` (Linker)","Resolve symbols, combine into executable"]],"caption":"Compilation Phases Overview","headers":["Phase","Input","Output","Tool","Purpose"]},"type":"table"},{"data":{"icon":"Info","title":"Separate Compilation Model","content":"This pipeline enables **separate compilation**—each source file can be compiled independently into an object file. Only at the linking stage are all pieces combined. This dramatically improves build times for large projects, as unchanged files don't need recompilation.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"preprocessing","title":"Preprocessing: Textual Transformation","content":[{"data":{"content":"The **preprocessing stage** operates purely at the textual level. The preprocessor (historically `cpp` for C) knows nothing about the language's syntax or semantics—it performs pattern-matching and text substitution based on **preprocessor directives**.\n\n**Key operations performed during preprocessing:**\n\n- **Macro Expansion**: Replaces macro invocations with their definitions\n- **File Inclusion**: Inserts the contents of header files\n- **Conditional Compilation**: Includes or excludes code based on conditions\n- **Line Control**: Generates line number information for error messages\n- **Pragma Processing**: Handles compiler-specific directives"},"type":"text"},{"data":{"code":"// example.c - Before preprocessing\n#include \n\n#define MAX_BUFFER 1024\n#define SQUARE(x) ((x) * (x))\n\n#ifdef DEBUG\n #define LOG(msg) printf(\"[DEBUG] %s\n\", msg)\n#else\n #define LOG(msg) ((void)0)\n#endif\n\nint main() {\n char buffer[MAX_BUFFER];\n int result = SQUARE(5);\n LOG(\"Computation complete\");\n return 0;\n}","fileName":"example.c","language":"c","showLineNumbers":true},"type":"code"},{"data":{"content":"**After preprocessing** (with `-E` flag to see preprocessed output), the file transforms dramatically. The `#include ` expands to thousands of lines from the stdio header and its transitive includes. All macros are expanded inline:"},"type":"text"},{"data":{"code":"// ... thousands of lines from stdio.h ...\n// ... type definitions, function declarations ...\n\nint main() {\n char buffer[1024]; // MAX_BUFFER replaced\n int result = ((5) * (5)); // SQUARE(5) expanded\n ((void)0); // LOG expanded (DEBUG not defined)\n return 0;\n}","fileName":"example.i (preprocessed, simplified)","language":"c","showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"Inspecting Preprocessor Output","content":"Use `gcc -E source.c -o source.i` to see the preprocessed file. This is invaluable for debugging macro-related issues. The output can be enormous due to header expansion—a simple 10-line program might produce 50,000+ lines after preprocessing.","variant":"tip"},"type":"callout"},{"data":{"content":"**Header guards and pragma once:**\n\nBecause the preprocessor performs literal text inclusion, the same header might be included multiple times (through different paths), causing redefinition errors. **Header guards** prevent this:"},"type":"text"},{"data":{"code":"#ifndef MYHEADER_H // If not already defined\n#define MYHEADER_H // Define the guard macro\n\n// Header contents here\ntypedef struct {\n int x;\n int y;\n} Point;\n\nvoid process_point(Point* p);\n\n#endif // MYHEADER_H","fileName":"myheader.h","language":"c","showLineNumbers":true},"type":"code"},{"data":{"content":"Modern compilers also support `#pragma once` as a simpler alternative, though it's not part of the C standard. The preprocessor's textual nature has important implications:\n\n- **No type checking**: Macros have no type safety\n- **No scope**: Macros affect everything after their definition\n- **Side effects**: `SQUARE(x++)` would evaluate `x++` twice\n\nUnderstanding these limitations is crucial for writing robust code and debugging preprocessor-related issues."},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"compilation-proper","title":"Compilation Proper: From Source to Assembly","content":[{"data":{"content":"The **compilation proper** stage is where the real linguistic transformation occurs. The compiler takes preprocessed source code and produces assembly language—a human-readable representation of machine instructions. This stage itself involves multiple sophisticated sub-phases:\n\n**Frontend phases:**\n1. **Lexical Analysis** — Breaking source into tokens\n2. **Syntax Analysis** — Building a parse tree\n3. **Semantic Analysis** — Type checking, scope resolution\n\n**Middle-end phases:**\n4. **Intermediate Representation (IR)** — Platform-independent code form\n5. **Optimization** — Improving code efficiency\n\n**Backend phases:**\n6. **Code Generation** — Producing assembly for target architecture\n7. **Target-specific Optimization** — Architecture-specific improvements"},"type":"text"},{"data":{"height":"250px","mermaidSyntax":"flowchart LR\n A[Source Code] --> B[Lexer]\n B --> C[Parser]\n C --> D[Semantic Analyzer]\n D --> E[IR Generator]\n E --> F[Optimizer]\n F --> G[Code Generator]\n G --> H[Assembly]\n \n style B fill:#e1f5fe\n style C fill:#e1f5fe\n style D fill:#e1f5fe\n style E fill:#fff3e0\n style F fill:#fff3e0\n style G fill:#e8f5e9\n style H fill:#e8f5e9"},"type":"mermaid-excalidraw"},{"data":{"content":"### Lexical Analysis (Tokenization)\n\nThe **lexer** (or scanner) reads the character stream and groups characters into **tokens**—the fundamental units of the language. Each token has a type and value:"},"type":"text"},{"data":{"code":"// Source code\nint count = 42;\n\n// Token stream produced by lexer:\n// TOKEN_KEYWORD_INT : \"int\"\n// TOKEN_IDENTIFIER : \"count\"\n// TOKEN_ASSIGN : \"=\"\n// TOKEN_INTEGER_LITERAL: \"42\"\n// TOKEN_SEMICOLON : \";\"","fileName":"Lexical Analysis Example","language":"c","showLineNumbers":true},"type":"code"},{"data":{"content":"### Syntax Analysis (Parsing)\n\nThe **parser** consumes the token stream and constructs an **Abstract Syntax Tree (AST)**—a hierarchical representation of the program's grammatical structure. The AST captures the essential structure while discarding syntactic noise like parentheses and semicolons."},"type":"text"},{"data":{"code":"// Expression: a + b * c\n\n// AST structure (+ has lower precedence than *)\n// (+)\n// / \\\n// (a) (*)\n// / \\\n// (b) (c)\n\n// This correctly represents that b*c is computed first","fileName":"AST Example","language":"text","showLineNumbers":false},"type":"code"},{"data":{"content":"### Semantic Analysis\n\n**Semantic analysis** adds meaning to the syntax tree. This phase performs:\n\n- **Type Checking**: Ensuring operations are type-compatible\n- **Scope Resolution**: Matching identifiers to declarations\n- **Declaration Checking**: Verifying variables are declared before use\n- **Type Coercion**: Inserting implicit conversions where needed\n\nAfter semantic analysis, the compiler has a complete understanding of the program's meaning and can detect errors like:\n- Using an undeclared variable\n- Type mismatches in assignments\n- Invalid function call arguments\n- Duplicate declarations in the same scope"},"type":"text"},{"data":{"icon":"AlertCircle","title":"Frontend vs Backend Errors","content":"Errors detected in the frontend (lexer, parser, semantic analyzer) are **compile-time errors** that prevent code generation. These include syntax errors, type mismatches, and undefined references. Understanding this distinction helps in debugging: if the compiler rejects your code, the issue is in these early phases.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"ir-optimization","title":"Intermediate Representation and Optimization","content":[{"data":{"content":"Modern compilers don't translate directly from AST to assembly. Instead, they use an **Intermediate Representation (IR)**—a platform-independent code format that serves as the target for optimization. Popular IRs include:\n\n- **LLVM IR**: Used by Clang, Rust, Swift\n- **GCC GIMPLE/RTL**: Used by GCC\n- **JVM Bytecode**: Used by Java compilers\n\nThe IR provides a uniform representation that allows optimizations to be written once and applied regardless of source language or target architecture."},"type":"text"},{"data":{"code":"; Original C code:\n; int square(int x) { return x * x; }\n\ndefine i32 @square(i32 %x) {\nentry:\n %mul = mul nsw i32 %x, %x\n ret i32 %mul\n}\n\n; LLVM IR uses typed registers (%x, %mul)\n; Instructions are in SSA (Static Single Assignment) form\n; Each register is assigned exactly once","fileName":"LLVM IR Example","language":"llvm","showLineNumbers":true},"type":"code"},{"data":{"content":"### Optimization Techniques\n\nThe optimizer transforms the IR to produce faster and/or smaller code. Optimizations operate at different levels:\n\n**Local optimizations** (within a basic block):\n- **Constant folding**: Evaluate `3 + 4` at compile time to `7`\n- **Strength reduction**: Replace `x * 2` with `x << 1`\n- **Dead code elimination**: Remove unreachable code\n\n**Global optimizations** (across basic blocks):\n- **Common subexpression elimination**: Compute `a + b` once if used multiple times\n- **Loop-invariant code motion**: Move invariant computations outside loops\n- **Inline expansion**: Replace function calls with function body\n\n**Interprocedural optimizations** (across functions):\n- **Function inlining**: Insert function body at call sites\n- **Devirtualization**: Replace virtual calls with direct calls\n- **Link-time optimization (LTO)**: Optimize across compilation units"},"type":"text"},{"data":{"left":[{"data":{"code":"int example(int n) {\n int x = 3 + 4; // Constant expression\n int y = x * 2; // Multiply by power of 2\n int sum = 0;\n for (int i = 0; i < n; i++) {\n int base = 10; // Loop invariant\n sum += base * i;\n }\n int unused = 42; // Dead code\n return sum + y;\n}","fileName":"Before Optimization","language":"c","showLineNumbers":true},"type":"code"}],"right":[{"data":{"code":"int example(int n) {\n // x = 7 (constant folded)\n // y = 14 (7 * 2, constant folded)\n int sum = 0;\n // base = 10 hoisted outside loop\n for (int i = 0; i < n; i++) {\n sum += 10 * i; // Or: sum += (i << 1) + (i << 3)\n }\n // unused eliminated\n return sum + 14;\n}","fileName":"After Optimization","language":"c","showLineNumbers":true},"type":"code"}]},"type":"two-column"},{"data":{"icon":"Lightbulb","title":"Optimization Levels","content":"Compilers provide optimization flags: `-O0` (no optimization, fast compile), `-O1` (basic optimizations), `-O2` (most optimizations), `-O3` (aggressive including vectorization), `-Os` (optimize for size). Higher levels improve performance but increase compile time and may make debugging harder.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"code-generation","title":"Code Generation: Producing Assembly","content":[{"data":{"content":"The **code generator** transforms optimized IR into assembly language for the target architecture. This phase must handle:\n\n- **Instruction Selection**: Choosing target instructions for IR operations\n- **Register Allocation**: Mapping virtual registers to physical registers\n- **Instruction Scheduling**: Ordering instructions to minimize pipeline stalls\n- **Calling Convention Compliance**: Following ABI for function calls\n\nThe output is assembly language—a human-readable representation of machine instructions."},"type":"text"},{"data":{"code":"; C source: int add(int a, int b) { return a + b; }\n; Compiled with gcc -S -O2 for x86-64\n\n .text\n .globl add\n .type add, @function\nadd:\n .cfi_startproc\n leal (%rdi,%rsi), %eax ; Compute a + b using LEA\n ret ; Return (result in %eax)\n .cfi_endproc\n .size add, .-add\n\n; Note: Arguments passed in %edi (a) and %esi (b) per System V ABI\n; Result returned in %eax\n; LEA (Load Effective Address) performs addition without affecting flags","fileName":"x86-64 Assembly Output","language":"asm","showLineNumbers":true},"type":"code"},{"data":{"content":"### Register Allocation\n\nOne of the most challenging aspects of code generation is **register allocation**. The IR uses unlimited virtual registers, but physical CPUs have limited registers (x86-64 has 16 general-purpose registers). The allocator must:\n\n1. **Compute live ranges** — When is each value needed?\n2. **Build interference graph** — Which values can't share registers?\n3. **Color the graph** — Assign registers minimizing conflicts\n4. **Handle spills** — Store values to memory when registers exhausted\n\nPoor register allocation forces values to be stored in memory (\"spilled\"), dramatically slowing execution since memory access is 100x slower than register access."},"type":"text"},{"data":{"rows":[["RAX","%rax","%eax","%ax","%al","Return value, accumulator"],["RBX","%rbx","%ebx","%bx","%bl","Callee-saved, base pointer"],["RCX","%rcx","%ecx","%cx","%cl","4th argument, counter"],["RDX","%rdx","%edx","%dx","%dl","3rd argument, I/O"],["RSI","%rsi","%esi","%si","%sil","2nd argument, source index"],["RDI","%rdi","%edi","%di","%dil","1st argument, dest index"],["RSP","%rsp","%esp","%sp","%spl","Stack pointer (reserved)"],["RBP","%rbp","%ebp","%bp","%bpl","Base pointer, callee-saved"]],"caption":"x86-64 General Purpose Registers","headers":["Register","64-bit","32-bit","16-bit","8-bit low","Purpose/Convention"]},"type":"table"},{"data":{"icon":"Info","title":"ABI Compliance","content":"The **Application Binary Interface (ABI)** defines calling conventions, register usage, and stack layout. On Linux x86-64, the System V ABI specifies that the first six integer arguments go in RDI, RSI, RDX, RCX, R8, R9. Understanding the ABI is essential for debugging, writing assembly, or interfacing with libraries.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"assembly-stage","title":"Assembly Stage: From Mnemonics to Machine Code","content":[{"data":{"content":"The **assembler** (`as` on Unix systems) translates assembly language into machine code, producing an **object file**. This transformation is relatively straightforward—mostly a one-to-one mapping of mnemonics to binary instruction encodings—but involves several important operations:\n\n1. **Instruction Encoding**: Converting mnemonics to binary opcodes\n2. **Symbol Table Creation**: Recording addresses of labels and functions\n3. **Relocation Entry Generation**: Marking addresses that need adjustment\n4. **Section Organization**: Grouping code, data, and metadata"},"type":"text"},{"data":{"code":"; Assembly instruction\nmov $42, %eax ; Move immediate 42 into EAX\n\n; Binary encoding (little-endian x86-64)\n; B8 2A 00 00 00\n; ^^ ^^^^^^^^^^\n; | 42 in little-endian (0x0000002A)\n; Opcode for \"mov imm32, eax\"\n\n; The assembler performs this translation for every instruction\n; and produces the final object file with:\n; - .text section: machine code\n; - .data section: initialized data\n; - .bss section: uninitialized data\n; - .symtab: symbol table\n; - .rela.*: relocation entries","fileName":"Assembly to Machine Code","language":"asm","showLineNumbers":true},"type":"code"},{"data":{"content":"### Symbol Table\n\nThe assembler creates a **symbol table** recording every label, function, and global variable defined or referenced in the file. Each entry contains:\n\n- **Name**: The symbol's identifier\n- **Value**: The current address or offset\n- **Size**: For data symbols, the size in bytes\n- **Binding**: Local (file-scoped) or Global (visible to linker)\n- **Type**: Function, Object (data), Section, etc.\n- **Section**: Which section contains this symbol\n\nSymbols can be **defined** (have an address in this file) or **undefined** (reference external symbols to be resolved during linking)."},"type":"text"},{"data":{"code":"$$ nm example.o\n0000000000000000 T main ; Defined in .text, global\n U printf ; Undefined, external reference\n0000000000000000 D global_var ; Defined in .data, global\n0000000000000004 d local_static ; Defined in .data, local\n0000000000000000 B uninitialized ; Defined in .bss, global\n\n# Symbol types:\n# T/t = text (code), D/d = data, B/b = BSS\n# Uppercase = global, lowercase = local\n# U = undefined (external reference)","fileName":"Symbol Table Example (nm output)","language":"bash","showLineNumbers":true},"type":"code"},{"data":{"content":"### Relocation Entries\n\nWhen the assembler encounters a reference to a symbol whose address isn't yet known (like an external function or a global variable in the same file at a location not yet settled), it generates a **relocation entry**. This entry tells the linker:\n\n- **Where** in the code the address reference occurs\n- **Which symbol** is being referenced\n- **How** to compute the final address (relocation type)\n\nRelocation allows object files to be compiled independently without knowing the final memory layout."},"type":"text"},{"data":{"icon":"AlertCircle","title":"Object Files Are Not Executable","content":"Object files (`.o`) contain machine code but cannot be executed directly. They have unresolved symbols (external references) and contain addresses that assume the code starts at address 0. The linker must combine object files, resolve symbols, and perform relocations to create an executable.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"complete-example","title":"Complete Example: Tracing the Pipeline","content":[{"data":{"content":"Let's trace a simple program through the entire compilation process to solidify understanding. We'll use GCC with flags to observe each stage."},"type":"text"},{"data":{"code":"#include \n\n#define GREETING \"Hello, World!\"\n\nint main() {\n printf(\"%s\n\", GREETING);\n return 0;\n}","fileName":"hello.c","language":"c","showLineNumbers":true},"type":"code"},{"data":{"code":"# Step 1: Preprocessing only\ngcc -E hello.c -o hello.i\n# hello.i contains expanded stdio.h and GREETING macro\n\n# Step 2: Compilation to assembly\ngcc -S hello.i -o hello.s\n# hello.s contains x86-64 assembly\n\n# Step 3: Assembly to object file\ngcc -c hello.s -o hello.o\n# hello.o is an ELF object file\n\n# Step 4: Linking to executable\ngcc hello.o -o hello\n# hello is the final executable\n\n# Or all at once:\ngcc hello.c -o hello","fileName":"Compilation Commands","language":"bash","showLineNumbers":true},"type":"code"},{"data":{"code":" .file \"hello.c\"\n .section .rodata\n.LC0:\n .string \"Hello, World!\" ; GREETING expanded\n .text\n .globl main\n .type main, @function\nmain:\n pushq %rbp ; Save frame pointer\n movq %rsp, %rbp ; Set up stack frame\n leaq .LC0(%rip), %rdi ; Load address of string\n call puts@PLT ; Call puts (printf optimized)\n movl $0, %eax ; Return 0\n popq %rbp ; Restore frame pointer\n ret\n .size main, .-main","fileName":"hello.s (Assembly Output, simplified)","language":"asm","showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"Compiler Optimizations in Action","content":"Notice that GCC replaced `printf(\"%s\n\", str)` with `puts(str)`. This is a common optimization—`puts` is simpler and faster for printing strings with newlines. The compiler recognized the pattern and substituted a more efficient function.","variant":"tip"},"type":"callout"},{"data":{"content":"### Examining the Object File\n\nWe can use tools to inspect the generated object file:"},"type":"text"},{"data":{"code":"$$ objdump -d hello.o\nhello.o: file format elf64-x86-64\n\nDisassembly of section .text:\n\n0000000000000000

:\n 0: 55 push %rbp\n 1: 48 89 e5 mov %rsp,%rbp\n 4: 48 8d 3d 00 00 00 00 lea 0x0(%rip),%rdi # Address TBD\n b: e8 00 00 00 00 call 10 # Needs relocation\n 10: b8 00 00 00 00 mov $0x0,%eax\n 15: 5d pop %rbp\n 16: c3 ret\n\n$ readelf -r hello.o\nRelocation section '.rela.text' at offset 0x1c0 contains 2 entries:\n Offset Type Symbol\n000000000007 R_X86_64_PC32 .rodata-0x4 ; Address of string\n00000000000c R_X86_64_PLT32 puts-0x4 ; Call to puts","fileName":"Object File Analysis","language":"bash","showLineNumbers":true},"type":"code"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: The Compilation Pipeline","content":[{"data":{"content":"The compilation process is a sophisticated pipeline that transforms human-readable source code into machine-executable object files. Each stage has a precise purpose:"},"type":"text"},{"data":{"type":"ordered","items":["**Preprocessing** performs textual substitution—macro expansion, file inclusion, conditional compilation—without understanding the language's semantics.","**Compilation proper** parses the source, checks types, optimizes the IR, and generates assembly language for the target architecture.","**Assembly** converts human-readable mnemonics to binary machine code, creating the object file with symbol tables and relocation entries.","**Object files are incomplete**—they contain unresolved symbols and relocatable addresses that the linker must fix.","**Modern compilers use IR** (like LLVM IR) to enable sophisticated optimizations independent of source language or target architecture.","**Understanding this pipeline is essential** for debugging, performance analysis, and comprehending how programs interact with memory."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nNow that we understand how individual source files are compiled into object files, the next page explores **object files** in detail—their structure, formats (ELF, COFF, Mach-O), sections, and the metadata they contain that enables linking and loading."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the complete compilation process—from preprocessing through assembly. This knowledge is foundational for understanding how the operating system manages programs in memory and how linking resolves the relationships between separately-compiled modules.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_6395b26409ecc4e8ceb9e2a89a42ff5a","title":"Object Files","order":1,"content":null,"isLocked":true},{"id":"seed_3aefd25ddff1bd7574136fc5278e5af3","title":"Linking (Static and Dynamic)","order":2,"content":null,"isLocked":true},{"id":"seed_cb911e18150b56126917963e5eb39f7c","title":"Loading Process","order":3,"content":null,"isLocked":true},{"id":"seed_fd6081e973283aa2e65a3dd69361512e","title":"Relocatable Code","order":4,"content":null,"isLocked":true}]}}