---
config:
themeVariables:
fontFamily: 'monospace'
fontSize: '14px'
---
classDiagram
class STRTAB {
+Index 0 -> "\0"
+Index 1 -> "_shared_int\0"
+Index 13 -> "_shared_float\0"
+Index 27 -> "_main\0"
+Index 33 -> "_shared_func\0"
}
class SYMTAB {
<<Master Table>>
+Index 0 -> (n_strx=27, ..., n_sect=15, type="SECT", str="_main")
+Index 1 -> (n_strx=13, ..., n_sect=1, type="UNDF", str="shared_float")
+Index 2 -> (n_strx=33, ..., n_sect=1, type="UNDF", str="shared_func")
+Index 3 -> (n_strx=1, ..., n_sect=1, type="UNDF", str="shared_int")
}
class DYSYMTAB {
<<Index View>>
+ilocalsym = 0
+nlocalsym = 0
+iextdefsym = 0
+nextdefsym = 1
+iundefsym = 1
+nundefsym = 3
}
class RELOC_ENTRIES {
<<Junction Table>>
+address 0x00000053 -> (pcrel=True, ..., type="BRANCH", symbol_num=2, value="_shared_func")
+address 0x0000004c -> (pcrel=True, ..., type="BRANCH", symbol_num=2, value="_shared_func")
+address 0x00000045 -> (pcrel=True, ..., type="BRANCH", symbol_num=2, value="_shared_func")
+address 0x00000032 -> (pcrel=True, ..., type="GOT_LD", symbol_num=1, value="_shared_float")
+address 0x0000001f -> (pcrel=True, ..., type="GOT_LD", symbol_num=1, value="_shared_float")
+address 0x00000012 -> (pcrel=True, ..., type="GOT_LD", symbol_num=3, value="_shared_int")
}
class ADDRESS_SPACE {
<<Master Table>>
+address 0x00000012 -> (machine_code=0x00000000, assembly="disp32<\%rip>")
+address 0x0000001f -> (machine_code=0x00000000, assembly="disp32<\%rip>")
+address 0x00000032 -> (machine_code=0x00000000, assembly="disp32<\%rip>")
+address 0x00000045 -> (machine_code=0x00000000, assembly="disp32<\%rip>")
+address 0x0000004c -> (machine_code=0x00000000, assembly="disp32<\%rip>")
+address 0x00000053 -> (machine_code=0x00000000, assembly="disp32<\%rip>")
}
SYMTAB ..> STRTAB : "FK Lookup (n_strx)"
SYMTAB <-- DYSYMTAB : "Slices / Filters"
RELOC_ENTRIES ..> SYMTAB : "JOIN (symbol_num -> Index)"
RELOC_ENTRIES ..> ADDRESS_SPACE : "JOIN (address -> address)"
(address, symbol, ...) 的 occurrences这个 system design 还是很工整的。
]]>Throughout this series, compiler refers to the compiler proper: the component that translates C $\Rightarrow$ Assembly. Producing an executable is treated as a separate static linking phase, orchestrated by a compiler driver, such as gcc and clang.
In the gcc toolchain, cc1 is the compiler proper; while in clang, it’s clang -cc1
gcc hello.c
├─ cc1 # C front-end + optimizer + code generation
├─ as # GNU assembler
└─ ld # GNU linker
clang hello.c
├─ clang -cc1 # front-end + LLVM IR + optimization + codegen
├─ as # system assembler (or integrated assembler)
└─ ld # system linker (e.g., ld64 on macOS)
Static Linking 是一个组合动作，它由 Symbol Resolution 和 Relocation 这两大核心步骤组成。而这两步理论上都是由 Static Linker 完成的，虽然 compiler 和 assembler 的 precursor jobs 是不可或缺的，但这些 precursor jobs 是不算在 static linking 的过程中的。
我始终觉得这里缺一个更大的概念或者名称来包含这些 precursor jobs 和 static linking，不如我们称其 Materialization of External Symbols:
┌───────────────────────────────────────┐
│ Materialization of External Symbols │
│ ┌────────────────────────────┐ │
│ │ Compiler's Precursor Job │ │
│ └────────────────────────────┘ │
│ \/ │
│ ┌─────────────────────────────┐ │
│ │ Assembler's Precursor Job │ │
│ └─────────────────────────────┘ │
│ \/ │
│ ┌─────────────────────────────────┐ │
│ │ Static Linker's Static Linking │ │
│ └─────────────────────────────────┘ │
└───────────────────────────────────────┘
更具体一点的话：
[ main.c ]
+-------------------+
| High-level logic |
+-------------------+
|
v
(( COMPILER )) <-- PERFORMER: Lexical/Syntax/Semantics Analysis + Codegen for C
| READS: C/C++ Code
| WRITES: Assembly with "Hints" (@GOT, etc.)
v
[ main.s ]
+-----------+
| Assembly |
+-----------+
|
v
(( ASSEMBLER )) <-- PERFORMER: Lexical/Syntax + Codegen for Assembly
| READS: Assembly & Directives
| WRITES: Machine code + Metadata
v
[ OBJECT.o ] (The "Incomplete" Binary)
+---------------------------------------------+
| .text : Instructions with 0x00 holes |
| .symtab : List of defined/undefined names |
| .reloc : The "Sticky Notes" for Linker |
+---------------------------------------------+
|
| (Combined with other [ .o ] and [ .a ] files)
v
(( STATIC LINKER )) <-- PERFORMER: The "straightforward" Static Linking
|
| PHASE 1: SYMBOL RESOLUTION
| - Scans all .symtab sections.
| - Matches "Undefined" names to "Global" addresses.
|
| PHASE 2: RELOCATION
| - Scans all .reloc entries.
| - Patches the 0x00 holes in .text with real addresses.
|
v
[ EXECUTABLE ] (The "Complete" Binary)
+---------------------------------------------+
| .text : Final code with hardcoded jumps |
| .data : Variables in fixed locations |
+---------------------------------------------+
compiler 为 symbol materialization 做的 precursor job 基本上就是给 assembler 留一些 hint. 比如我们在 .s assembly 里看到的是：
movq _shared_int@GOTPCREL(%rip), %rax
[!info] 注意这是 AT&T 汇编语法，与 Intel 语法略有不同
_shared_int 是 symbol name@GOTPCREL 整体是 relocation modifier
GOTPCREL 是 relocation type(%rip) 是 base registerassembler 看到这一句自然就明白了这里需要一个 reloc.
除了 _shared_int@GOTPCREL(%rip) 这种明显的，assembler 自己还有其他的判断 external symbols 的方法。我们可能长久忽略的一个事情是：assembler 本身就是一个 Assembly 的 parser, 它对 symbol 的判断能力是毋庸置疑的。
[!faq] 你可能要疑问：“external symbol 的识别” 工作为什么在 compiler 层面做了一遍之后，在 assembler 层面还要做一遍？
这是 C 编译器的 stage-wise 或者说 stage-independent compilation 的设计。简单说就是相比这么点 overhead，我们更 value 这种设计的 “Separation of Concerns”.
还是用同一句 instruction，对比一下有：
movq _shared_int@GOTPCREL(%rip), %rax # `.s` assembly (by compiler)
movq (%rip), %rax # `.o` assembly (by assembler)
这里 assembler 对 _shared_int 这个 external symbol 做了这么几件事情：
_shared_int@GOTPCREL 的 $\operatorname{displacement}$ 置 $0$_shared_int@GOTPCREL 写了一条 reloc 供 static linker 参考具体的工作流参考 Mach-O Stitching #7: How to Interpret Relocs (Relocation Entries).
这里额外提一下 symbol resolution 和 relocation 的分界线，有点微妙：
x in file_A.o and finds the definition of x in file_B.o. Symbol resolution for x is now complete.x will be located in the final memory map, it goes back to x’s reloc.address and overwrites the zeros with the real address. Relocation for x is now complete.| Type | Constant | Fully Linked? | Description |
|---|---|---|---|
| Object | MH_OBJECT |
❌ | Compiler output (.o files) - intermediate files that need linking |
| Executable | MH_EXECUTE |
✅ | Runnable program - standard application binary |
| Dynamic Library | MH_DYLIB |
✅ | Shared library (.dylib files) - code shared between programs |
| Bundle | MH_BUNDLE |
✅ | Loadable plugin (.bundle, .plugin) - dynamically loaded modules |
| Core Dump | MH_CORE |
N/A | Crash dump - memory snapshot of crashed process |
| Dynamic Linker | MH_DYLINKER |
✅ | The dyld program itself - loads and links dynamic libraries at runtime |
| Preload | MH_PRELOAD |
✅ | Fixed address executable - loads at predetermined memory location |
| Kernel Extension | MH_KEXT_BUNDLE |
❌ | Kernel module (.kext) - loadable kernel extension |
| Debug Symbols | MH_DSYM |
N/A | Debug info (.dSYM bundles) - debugging symbols for crash analysis |
| Dylib Stub | MH_DYLIB_STUB |
Partial | Linking stub - contains only symbols, no actual code |
| Fixed VM Shared Library | MH_FVMLIB |
✅ | Obsolete - old-style fixed virtual memory shared library |
Note that:
__LINKEDIT segment
MH_FVMLIB are rarely seen in modern systemsYou can check the file type of any Mach-O file using:
ᐅ otool -hv <file>
The filetype field in the Mach header will show the type.
[!NOTE]
ldanddyldon MacOS
ld== Link eDitor, the static linkerdyld== DYnamic Link eDitor, the dynamic linker
A Mach-O file contains three major regions:
__TEXT: contains executable code and other read-only data (yes, code is read-only of course)__DATA: contains writable data__LD: staging data for the static linker__LINKEDIT: in user-level fully linked Mach-O files, the last segment is the link edit segment, which contains raw data used by the dynamic linker, such as symbol, string, and relocation table entries__PAGEZERO: a 4GB (on 64-bit) region of virtual memory at address 0 with no protection rights assigned, which causes any accesses to NULL to crash.
__OBJC: contains data used by the Objective-C language runtime support libraryNote that an (relocatable) object file is not fully linked while an executable (object) file is. During static linking (i.e. during the process of main.o $\Rightarrow$ main.out), the following structural transformation occur:
__PAGEZERO Created__LINKEDIT Created__LD Consumption: The compiler-generated (__LD, __compact_unwind) section is consumed. The linker processes this metadata to synthesize the final, optimized (__TEXT, __unwind_info) section.__TEXT Refinement:
__DATA Refinement
dyld will resolve at runtime) to (__DATA, __got) (Global Offset Table)[!info]
__DATA_CONSTsegment and RELRO In modern Mach-O files,__gotis moved to a specific segment called__DATA_CONST. This allows the dynamic linker to write to them during load time (binding) and thenmprotectthem to read-only for the rest of the execution (a security feature called RELRO, Relocation Read-Only).
LC_MAIN is added to point the kernel to the address of the main() function.LC_LOAD_DYLINKER: Specifies the path to the dynamic linker (usually /usr/lib/dyld).LC_DYLD_INFO_ONLY: Contains the compressed “rebase” and “bind” opcodes used by dyld at startup.LC_LOAD_DYLIB: One command is added for every linked framework (e.g., libSystem).LC_SYMTAB is updated to remove local/temporary labels, and LC_DYSYMTAB is added to categorize symbols for the dynamic linker (local vs. defined external vs. undefined external).一个 object file 的结构大致如下：
┌─────────────────────────────────────────────────────────────┐
│ REGION 1 - MACH-O HEADER │
├─────────────────────────────────────────────────────────────┤
│ magic : 0xFEEDFACF (64-bit) │
│ cputype : CPU_TYPE_ARM64 │
│ cpusubtype : CPU_SUBTYPE_ARM64_ALL │
│ filetype : MH_OBJECT │
│ ncmds : Number of load commands │
│ sizeofcmds : Total size of load commands │
│ flags : MH_NOUNDEFS | MH_DYLDLINK | ... │
├─────────────────────────────────────────────────────────────┤
│ REGION 2 - LOAD COMMANDS │
├─────────────────────────────────────────────────────────────┤
│ │
│ ├─ LC_SEGMENT_64 (__TEXT) │
│ │ ├─ vmaddr : 0x100000000 │
│ │ ├─ vmsize : ... │
│ │ └─ sections : [__text, __stubs, __cstring, ...] │
│ │ │
│ ├─ LC_SEGMENT_64 (__DATA) │
│ │ ├─ vmaddr : ... │
│ │ ├─ vmsize : ... │
│ │ └─ sections : [__data, __bss, __common, ...] │
│ │ │
│ ├─ LC_SEGMENT_64 (__LD) │
│ │ ├─ vmaddr : ... │
│ │ ├─ vmsize : ... │
│ │ └─ filesize : ... │
│ │ │
│ ├─ LC_SYMTAB │
│ │ ├─ symoff : Symbol table offset │
│ │ ├─ nsyms : Number of symbols │
│ │ ├─ stroff : String table offset │
│ │ └─ strsize : String table size │
│ │ │
│ ├─ LC_UUID │
│ │ └─ uuid: [16 bytes] │
│ │ │
│ ├─ LC_FUNCTION_STARTS │
│ │ └─ Function start addresses │
│ │ │
│ ├─ LC_DATA_IN_CODE │
│ │ └─ Data-in-code entries │
│ │ │
│ └─ LC_CODE_SIGNATURE │
│ └─ Code signature offset and size │
│ │
├─────────────────────────────────────────────────────────────┤
│ REGION 3 - DATA │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ __TEXT SEGMENT │ │
│ ├───────────────────────────────────────────────────────┤ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ __text SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ Executable machine code (your compiled code) │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ __const SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ Initialized constant variables │ │ │
│ │ │ (The compiler places all nonrelocatable data │ │ │
│ │ │ declared `const` in this section.) │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ __cstring SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ C string literals │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ __literal4 SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ 4-byte literal values (single-precision floats) │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ __literal8 SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ 8-byte literal values (double-precision floats) │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ __stubs SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ Symbol stubs │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ __eh_frame SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ Exception handling frame information │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ __DATA SEGMENT │ │
│ ├───────────────────────────────────────────────────────┤ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ __data SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ Initialized mutable variables │ │ │
│ │ │ (such as writable C strings and data arrays) │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ __const SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ Initialized relocatable constant variables │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ __bss SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ uninitialized static variables │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ __common SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ Uninitialized imported symbol definitions │ │ │
│ │ │ located in the global scope │ │ │
│ │ │ (i.e. outside of any function declaration) │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ __dyld SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ Placeholder section used by the dynamic linker │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ ____mod_init_func SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ Module initialization functions │ │ │
│ │ │ (e.g. C++ static constructors) │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ ____mod_term_func SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ Module termination functions │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ __LD SEGMENT │ │
│ ├───────────────────────────────────────────────────────┤ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ __compact_unwind SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ Compact unwind information │ │ │
│ │ │ (for exception handling/stack unwinding) │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
如果它被 fully linked 成 executable, 那么会有如下的 load command 增量：
┌─────────────────────────────────────────────────────────────┐
│ REGION 2 - LOAD COMMANDS │
├─────────────────────────────────────────────────────────────┤
│ │
│ ├─ LC_SEGMENT_64 (__PAGEZERO) │
│ │ ├─ vmaddr : 0x0 │
│ │ ├─ vmsize : 0x100000000 │
│ │ └─ filesize : 0 │
│ │ │
│ ├─ LC_SEGMENT_64 (__LINKEDIT) │
│ │ ├─ vmaddr : ... │
│ │ ├─ vmsize : ... │
│ │ └─ filesize : ... │
│ │ │
│ ├─ LC_DYSYMTAB │
│ │ └─ Dynamic linking metadata │
│ │ │
│ ├─ LC_DYLD_INFO_ONLY │
│ │ ├─ rebase_off │
│ │ ├─ bind_off │
│ │ ├─ weak_bind_off │
│ │ ├─ lazy_bind_off │
│ │ └─ export_off │
│ │ │
│ ├─ LC_LOAD_DYLINKER │
│ │ └─ name: /usr/lib/dyld │
│ │ │
│ ├─ LC_LOAD_DYLIB │
│ │ └─ name: /usr/lib/libSystem.B.dylib │
│ │ │
│ └─ LC_MAIN │
│ └─ Entry point │
└─────────────────────────────────────────────────────────────┘
且会有如下的 segment 增量：
┌─────────────────────────────────────────────────────────────┐
│ REGION 3 - DATA │
├─────────────────────────────────────────────────────────────┤
│ ┌───────────────────────────────────────────────────────┐ │
│ │ __TEXT SEGMENT │ │
│ ├───────────────────────────────────────────────────────┤ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ __unwind_info SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ Unwinding information for exception handling │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ __DATA SEGMENT │ │
│ ├───────────────────────────────────────────────────────┤ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ __got SECTION │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ Global offset table │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ __LINKEDIT SEGMENT │ │
│ ├───────────────────────────────────────────────────────┤ │
│ │ ├─ Rebase Information │ │
│ │ │ └─ Addresses to adjust on load │ │
│ │ │ │ │
│ │ ├─ Binding Information │ │
│ │ │ ├─ Regular bindings │ │
│ │ │ ├─ Weak bindings │ │
│ │ │ └─ Lazy bindings │ │
│ │ │ │ │
│ │ ├─ Export Information │ │
│ │ │ └─ Exported symbols trie │ │
│ │ │ │ │
│ │ ├─ Symbol Table (SYMTAB) │ │
│ │ │ ├─ nlist_64 entries │ │
│ │ │ └─ Symbol definitions and references │ │
│ │ │ │ │
│ │ ├─ String Table (STRTAB) │ │
│ │ │ └─ Null-terminated symbol name strings │ │
│ │ │ │ │
│ │ ├─ Indirect Symbol Table │ │
│ │ │ └─ Indices into symbol table │ │
│ │ │ │ │
│ │ ├─ Relocation Entries (RELOCS) │ │
│ │ │ └─ Address fixup information │ │
│ │ │ │ │
│ │ ├─ Function Starts │ │
│ │ │ └─ Compressed function start addresses │ │
│ │ │ │ │
│ │ ├─ Data-in-Code │ │
│ │ │ └─ Non-instruction data in __text │ │
│ │ │ │ │
│ │ └─ Code Signature │ │
│ │ └─ Digital signature and entitlements │ │
│ └───────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
// vanilla.c
int a = 10; // stored in __DATA segment
int main() { // stored in __TEXT segment
return a;
}
ᐅ clang -c vanilla.c -o vanilla.o
ᐅ otool -h vanilla.o # Display the Mach-O header
vanilla.o:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
0xfeedfacf 16777223 3 0x00 1 4 520 0x00002000
如果看不懂这些 magic number，可以加上 -v 让 otool 显示 symbolic values:
ᐅ otool -hv vanilla.o
vanilla.o:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL 0x00 OBJECT 4 520 SUBSECTIONS_VIA_SYMBOLS
Header fields explained:
magic $\Rightarrow$ a magic number that identifies the Mach-O file format. E.g.:
0xfeedface $\Rightarrow$ big-endian 32-bit0xfeedfacf $\Rightarrow$ big-endian 64-bit0xcafebabe $\Rightarrow$ big-endian universalcputype $\Rightarrow$ identifies the CPU architecture family
16777223 == 0x1000007 $\Rightarrow$ CPU_TYPE_X86_64 (Intel/AMD 64-bit)
0x1000000 indicates 64-bit capability/usr/include/mach/machine.h for the definitionscpusubtype$\Rightarrow$ specifies CPU variant within the architecture family
3 $\Rightarrow$ CPU_SUBTYPE_X86_64_ALL (compatible with all x86_64 processors)caps$\Rightarrow$ CPU capability bits (rarely used, usually 0)filetype
1 $\Rightarrow$ MH_OBJECT (relocatable object file, like your .o file)2 $\Rightarrow$ MH_EXECUTE (executable)6 $\Rightarrow$ MH_DYLIB (dynamic library)8 $\Rightarrow$ MH_BUNDLE (loadable bundle)ncmds $\Rightarrow$ number of load commands (that describe segments, symbols, etc.) following the header
4 commands in your casesizeofcmds $\Rightarrow$ total size in bytes of all load commands
520 bytes in your caseflags $\Rightarrow$ misc. flags
0x2000 $\Rightarrow$ MH_SUBSECTIONS_VIA_SYMBOLS, which indicates the object file’s sections can be divided at symbol boundaries for dead code strippingLoad commands are instructions to the dynamic linker and loader that tell the operating system how to load and set up a program in memory when it’s executed.
Why do we need load commanders? When you run a program, the OS doesn’t just dump the file into memory and start executing. It needs to know some information or metadata, which is provided by load commands.
Common load commands include:
| Load Commands | Meaning |
|---|---|
LC_SEGMENT_64 |
“Map this segment at this address with these permissions” |
LC_LOAD_DYLIB |
“I need this library to run” (e.g., libc) |
LC_MAIN |
“Start execution at this offset” (entry point) |
LC_DYLD_INFO |
“Here’s binding/relocation info for dynamic linking” |
LC_CODE_SIGNATURE |
“Verify my code signature here” |
LC_SYMTAB |
“Symbol table is here” |
The loading process is like:
LC_SEGMENT_64, allocate memory, set permissions, copy dataLC_LOAD_DYLIB, recursively load dependenciesdyld performs symbol binding/relocationLC_MAIN// vanilla.c
int a = 10; // stored in __DATA segment
int main() { // stored in __TEXT segment
return a;
}
ᐅ clang -c vanilla.c -o vanilla.o
ᐅ otool -l vanilla.o # Display the load commands
LC_SEGMENT_64 $\Rightarrow$ 引导读取 segments/sectionsLoad command 0
cmd LC_SEGMENT_64
cmdsize 392
segname # segment name is empty, so this is an unnamed segment
vmaddr 0x0000000000000000 # Virtual Memory Address where this segment should be loaded
vmsize 0x0000000000000078 # Virtual Memory Size to hold this segment
fileoff 552 # this segment's content starts at file (i.e. `vanilla.o`) offset 472 (in byte)
filesize 120 # this segment's content is 112-byte long from `fileoff` in this file
maxprot 0x00000007 # 0x7 == Read (4) + Write (2) + Execute (1) permissions
initprot 0x00000007 # ditto
nsects 4 # this unnamed segment has 4 sections
flags 0x0
Section # section #1 is (__TEXT, __text)
sectname __text # contains executable code
segname __TEXT
addr 0x0000000000000000
size 0x0000000000000013 # this section is 13-byte long
offset 552
align 2^4 (16)
reloff 672
nreloc 1
flags 0x80000400
reserved1 0
reserved2 0
Section # section #2 is (__DATA, __data)
sectname __data # contains initialized global and static variables
segname __DATA
addr 0x0000000000000014
size 0x0000000000000004
... ...
Section # section #3 is (__LD, __compact_unwind)
sectname __compact_unwind # contains unwinding information (in Apple's compact format)
segname __LD
addr 0x0000000000000018
size 0x0000000000000020
... ...
Section # section #4 is (__TEXT, __eh_frame)
sectname __eh_frame # contains Exception Handling Frame
segname __TEXT
addr 0x0000000000000038
size 0x0000000000000040
... ...
[!NOTE] 注意这个 unnamed segment 起到的是一个 “list of
(segment, section)” 的作用或者你理解成一个 meta-segment 也行
LC_BUILD_VERSION $\Rightarrow$ 引导 checking version compatibilityLoad command 1
cmd LC_BUILD_VERSION # Build's Metadata
cmdsize 24
platform 1 # magic number, meaning macOS
minos 13.0 # minimum OS version is macOS 13.0 (Ventura)
sdk 14.2 # built with macOS 14.2 SDK (Sonoma)
ntools 0
LC_SYMTAB $\Rightarrow$ 引导读取 symtab/strtabLoad command 2
cmd LC_SYMTAB # Symbol Table
cmdsize 24
symoff 688 # symbol table is at file (i.e. `vanilla.o`) offset 688 (in byte)
nsyms 2 # there are 2 symbols
stroff 720 # string table is at file (i.e. `vanilla.o`) offset 720 (in byte)
strsize 16 # size of the string table is 16 bytes
[!info] FYI
The 2 symbols are:
ᐅ nm vanilla.o 0000000000000014 D _a 0000000000000000 T _main
T: the symbol is in(__TEXT, __text)D: the symbol is in(__DATA, __data)U: the symbol is undefined
LC_DYSYMTAB $\Rightarrow$ 提供 dynamic linking metadata```bash
Load command 3
cmd LC_DYSYMTAB # Dynamic Symbol Table
cmdsize 80
###########################################
# Partitions of the existing symbol table #
###########################################
# P1: local symbols (non-dynamic)
ilocalsym 0 # (next available) index (globally in the symtab) for locally defined symbols
nlocalsym 0 # count of locally defined symbols
# P2: exported symbols (type 1 of dynamic symbols)
iextdefsym 0 # (next available) index (globally in the symtab) for externally defined symbols
nextdefsym 2 # count of externally defined symbols (==1, should be the exported `_main`)
# P3: imported symbols (type 2 of dynamic symbols)
iundefsym 2 # (next available) index (globally in the symtab) for undefined symbols
nundefsym 0 # count of undefined symbols
################################
# Pointers to auxiliary tables #
################################
tocoff 0 # file offset for ToC (rarely used in modern Mach-O; was intended for organizing symbols in multi-module libraries)
ntoc 0 # count of ToC entries
modtaboff 0 # file offset for Module Table (rarely used in modern Mach-O; describes individual modules within a multi-module dylib)
nmodtab 0 # count of Module Table entries
extrefsymoff 0 # file offset for External Reference Table (describes how undefined symbols are used (lazy vs. non-lazy); contains flags indicating reference type)
nextrefsyms 0 # count of External Reference Table entries
indirectsymoff 0 # file offset for Indirect Symbol Table
nindirectsyms 0 # count of Indirect Symbol Table entries
extreloff 0 # file offset for External Relocation Entries
nextrel 0 # count of External Relocation Entries
locreloff 0 # file offser for Local Relocation Entries
nlocrel 0 # count of Local Relocation Entries
[!caution]
extdefmeans external & defined, not externally definedSee Mach-O Stitching #6: How to Interpret Dysymtab > Experiment Result.
A dynamic symbol is a symbol (function or variable name) that is either:
dylib) that will be linked at runtime
printfextern by default)[!caution] The name “dynamic symbol” is MISLEADING
dynamic symbol 并不意味着 dynamic linking: 它可能被 dynamic linker resolve, 也可能被 static linker resolve
[!caution] The name “dynamic symbol table” is MISLEADING
首先 there is NO such table as “dynamic symbol table”.
其次
LC_DYSYMTAB不仅仅包含了 dynamic symbol 的信息，它还有很多 auxiliary 的信息。
[!NOTE] Why
iundefsym = 2butnundefsym = 0?Because
iundefsym = 2means “if there were any undefined symbols, they would start at index2“. Note that symbol_mainand_ahave occupied indices0and1in our example.In short,
iundefsymis just pointing to where the undefined symbols would begin in the symbol table, andnundefsym = 0means there are actually no undefined symbols at that position.
[!NOTE] Symbol grouping in symtab
考虑到
LC_DYSYMTAB这样的设计，我们可以推测出：symtab 中的 symbols 必须要按照localsym/extdefsym/undefsym这样做了 grouping.symbols 在物理上是不能散乱地排列的。
]]>[!info] symbols 在组内的 sorting
对于
extdefsym和undefsym，Mach-O 还要求在组内按symbol name 进行排序。这意味着dyld可以使用 binary search 快速定位 symbol, 而不需要线性扫描。
// test.c
int global_elink = 1; // External Linkage => (__DATA,__data)
static int global_ilink = 3; // Internal Linkage => (__DATA,__data)
const int constant_val = 7; // Read-only => (__TEXT,__const)
void func() {
static int count = 15; // Static Storage => (__DATA,__data)
int local_val = 31; // Automatic Storage => Stack only, no symbol
global_ilink += 0; // global_ilink might be wiped as a dead symbol even when `clang -O0`
// this statement keeps it alive
}
ᐅ clang -O0 -c test.c -o test.o
__TEXT Segmentᐅ otool -tv test.o # Display the contents of the (__TEXT,__text) section.
# With the -v flag, this disassembles the text.
# With the -V flag, it also symbolically disassembles the operands.
test.o:
(__TEXT,__text) section
_func:
0000000000000000 pushq %rbp
0000000000000001 movq %rsp, %rbp
0000000000000004 movl $0x1f, -0x4(%rbp) # int local_val = 31;
000000000000000b movl (%rip), %eax
0000000000000011 addl $0x0, %eax
0000000000000014 movl %eax, (%rip)
000000000000001a popq %rbp
000000000000001b retq
ᐅ otool -v -s __TEXT __const test.o # Display the contents of the (__TEXT,__const) section.
test.o:
Contents of (__TEXT,__const) section
0000000000000018 07 00 00 00
#---# # const int constant_val = 7;
where 07 00 00 00 is little-endian 0x07 for const int constant_val = 7;.
__DATA Segmentᐅ otool -dv test.o
test.o:
(__DATA,__data) section
0000000000000010 01 00 00 00 0f 00 00 00 03 00 00 00
#---------# # int global_elink = 1;
#---------# # static int count = 15;
#---------# # static int global_ilink = 3;
where:
01 00 00 00 is little-endian 0x01 for int global_ext = 1;03 00 00 00 is little-endian 0x03 for static int global_ilink = 3;0f 00 00 00 is little-endian 0x0f for local static int count = 15;LC_SYMTAB $\Rightarrow$ 指定 symtab/strtab 的位置
我们继续沿用这个代码：
// vanilla.c
int a = 10; // stored in __DATA segment
int main() { // stored in __TEXT segment
return a;
}
ᐅ clang -c vanilla.c -o vanilla.o
ᐅ otool -l vanilla.o # Display the load commands
可得 LC_SYMTAB:
Load command 2
cmd LC_SYMTAB # Symbol Table
cmdsize 24
symoff 688 # symbol table is at file (i.e. `vanilla.o`) offset 688 (in byte)
nsyms 2 # there are 2 symbols
stroff 720 # string table is at file (i.e. `vanilla.o`) offset 720 (in byte)
strsize 16 # size of the string table is 16 bytes
nlist_64 $\Rightarrow$ symtab 的 entry如果我们 seek 到 file offset 688，可以查看 symtab 的 binary contents:
ᐅ xxd -s 688 -l 48 -a -d -e vanilla.o
# -s: start from <offset>
# -l: length to read
# -a: empty lines (like all '\0' values) are compactly represented by a '*'
# -d: use decimal addresses
# -e: use little-endian
00000688: 00000007 0000020f 00000014 00000000 # for symbol `_a`
00000704: 00000001 0000010f 00000000 00000000 # for symbol `_main`
00000720: 616d5f00 5f006e69 00000061 00000000 ._main._a.......
[!caution]
xxdwith-eoption shows little-endian比 big-endian 直观一点。
endianness 记不住的话，有一个诀窍：我们日常的计数都是 little-endian (least significant byte (LSB) at the lowest memory address).
symtab 的 entry/record 的 size 是 16 bytes. 每个 entry/record conceptually 是一个 struct nlist_64 object:
// See https://llvm.org/doxygen/BinaryFormat_2MachO_8h_source.html#l01017
struct nlist_64 {
uint32_t n_strx; // char index into the string table
uint16_t n_desc; // additional info for non-`N_STAB`-typed symbols
uint8_t n_sect; // number of the section that this symbol can be found in, or `NO_SECT` if the symbol is not to be found in any section.
uint8_t n_type; // type flag
uint64_t n_value; // this value is different for each type of symbol, e.g.
// for the `N_SECT` symbol type, this is the address (offset from the start of the segment) of the symbol.
// for `N_UNDF | N_EXT`, this is not used.
};
以 _a 这个 symbol 为例，binary contents 是这么划分的：
n_strx |
n_desc |
n_sect |
n_type |
n_value |
|---|---|---|---|---|
00000007 |
0000 |
02 |
0f |
00000014 00000000 |
| $4$ bytes | $2$ bytes | $1$ byte | $1$ byte | $8$ bytes |
objdump --syms 的结果与 nlist_64 也是对应的：
ᐅ objdump --syms vanilla.o
vanilla.o: file format mach-o-x86-64
SYMBOL TABLE:
0000000000000014 g 0f SECT 02 0000 [.data] _a
0000000000000000 g 0f SECT 01 0000 [.text] _main
# 0000000000000014 == n_value (big-endian)
# 0f == n_type == 0b 0000 1111
# => g == "global", i.e. EXTERNAL flag is set (from n_type)
# => SECT == symbol type is N_SECT (from n_type)
# 02 == n_sect
# 0000 == n_desc
# [.data] == section that this symbol is associated
# _a == name of this symbol
n_strx表示这个 symbol 对应的 string (i.e. 这个 symbol 的 name) 在 strtab 中的 index
[!caution] 注意这个 index 是 index of characters，不是 index of strings
比如
n_strx == 2表示 symbol name 的起始的 char 是strtab[2]，而不是表示 “the 2nd string”.
n_type是一个 byte value，我们会用以下 4 个 masks 去探测它的值：
\[\operatorname{n\_type} = \underbrace{b_{7} \, b_{6} \, b_{5}}_{\operatorname{N\_STAB}} \;\; \underbrace{b_{4}}_{\operatorname{N\_PEXT}} \;\; \underbrace{b_{3} \, b_{2} \, b_{1}}_{\operatorname{N\_TYPE}} \;\; \underbrace{b_{0}}_{\operatorname{N\_EXT}}\]N_EXT = 0x01 = 0b 0000 0001 // 查看 `n_type` 的 bit 0
N_TYPE = 0x0e = 0b 0000 1110 // 查看 `n_type` 的 bit 1,2,3, these bits define the type of the symbol.
N_PEXT = 0x10 = 0b 0001 0000 // 查看 `n_type` 的 bit 4
N_STAB = 0xe0 = 0b 1110 0000 // 查看 `n_type` 的 bit 5,6,7
/*************************/
/***** EXTERNAL flag *****/
/*************************/
if n_type & N_EXT == 1:
// This symbol is an EXTERNAL symbol,
// meaning this symbol is either defined outside this file,
// or is defined in this file but can be referenced by other files.
/************************/
/***** SYMBOL TYPES *****/
/************************/
switch (n_type & N_TYPE):
case N_UNDF == 0x0 == 0b 0000:
// This symbol is UNDEFINED.
// Undefined symbols are symbols referenced in this module but defined in a different module.
// The `n_sect` field is set to `NO_SECT`
case N_ABS == 0x2 == 0b 0010:
// This symbol is ABSOLUTE (considered DEFINED).
// The linker does not change the value of an absolute symbol.
// The `n_sect` field is set to `NO_SECT`.
case N_INDR == 0xa == 0b 1010:
// This symbol is DEFINED to be the same as another symbol.
// The `n_value` field is an index into the string table specifying the name of the other symbol.
// When that symbol is linked, both this and the other symbol have the same defined type and value.
case N_PBUD == 0xc == 0b 1100:
// This symbol is considered UNDEFINED and the image is using a PRE-BOUND value for the symbol.
// The `n_sect` field is set to `NO_SECT`.
case N_SECT == 0xe == 0b 1110:
// This symbol is DEFINED in the section number given in `n_sect`
/*********************************/
/***** PRIVATE EXTERNAL flag *****/
/*********************************/
if n_type & N_PEXT == 1:
// This symbol is marked as having limited global scope.
// When the file is fed to the static linker, it clears the `N_EXT` bit for each symbol with the
// `N_PEXT` bit set. (The `ld` option `-keep_private_externs` turns off this behavior.)
// With OS X GCC, you can use the `__private_extern__` function attribute to set this bit.
/***************************************************/
/***** SYMBOLIC-DEBUGGING TABLE (stab)-related *****/
/***************************************************/
if n_type & N_STAB != 0:
// If any of these 3 bits are set, the symbol is a `stab` entry.
// In that case, the entire `n_type` field is interpreted as a `stab` value.
// See `/usr/include/mach-o/stab.h` for valid `stab` values.
n_sectAn integer specifying the number of the section that this symbol can be found in, or NO_SECT if the symbol is not to be found in any section of this image. The sections are contiguously numbered across segments, starting from 1, according to the order they appear in the LC_SEGMENT load commands.
n_desc是一个 16-bit value，我们会用以下 3 类 bit masks 去探测它的值：
\[\operatorname{n\_desc} = \underbrace{b_{15} \, b_{14} \, b_{13} \, b_{12} \, b_{11} \, b_{10} \, b_{9} \, b_{8}}_{\text{library ordinal}} \;\; \underbrace{b_{7} \, b_{6} \, b_{5} \, b_{4}}_{\text{attribute flags}} \;\; \underbrace{b_{3} \, b_{2} \, b_{1} \, b_{0}}_{\operatorname{REFERENCE\_TYPE}}\]REFERENCE_TYPE = 0xF = 0b 0000 1111 // 查看 `n_desc` 的 bit 0,1,2,3
// 4 Attribute Flags
REFERENCED_DYNAMICALLY = 0x10 = 0b 0001 0000 // 查看 `n_desc` 的 bit 4
N_DESC_DISCARDED = 0x20 = 0b 0010 0000 // 查看 `n_desc` 的 bit 5
N_WEAK_REF = 0x40 = 0b 0100 0000 // 查看 `n_desc` 的 bit 6
N_WEAK_DEF = 0x80 = 0b 1000 0000 // 查看 `n_desc` 的 bit 7
/***************************/
/***** REFERENCE TYPES *****/
/***************************/
switch (n_desc & REFERENCE_TYPE):
/***** External References *****/
case REFERENCE_FLAG_UNDEFINED_NON_LAZY == 0x0 == 0b 0000:
// This symbol is a reference to an EXTERNAL NON-LAZY (data) symbol
// (like a global variable from another library).
case REFERENCE_FLAG_UNDEFINED_LAZY == 0x1 == 0b 0001:
// This symbol is a reference to an EXTERNAL LAZY (that will be resolved on first use) symbol
// (that is, to a function call).
/***** Local Definitions *****/
case REFERENCE_FLAG_DEFINED == 0x2 == 0b 0010:
// This symbol is DEFINED in this module and PUBLICLY VISIBLE.
case REFERENCE_FLAG_PRIVATE_DEFINED == 0x3 == 0b 0011:
// This symbol is DEFINED in this module and PRIVATELY VISIBLE
// only to modules within this shared library.
/***** Private Inter-Module References *****/
case REFERENCE_FLAG_PRIVATE_UNDEFINED_NON_LAZY == 0x4 == 0b 0100:
// This symbol is a reference to an NON-LAZY (data) symbol in another module in this file,
// and is PRIVATELY VISIBLE only to modules within this shared library.
case REFERENCE_FLAG_PRIVATE_UNDEFINED_LAZY == 0x5 == 0b 0101:
// This symbol is a reference to an LAZY (that will be resolved on first use) symbol
// (that is, to a function call) in another module in this file,
// and is PRIVATELY VISIBLE only to modules within this shared library.
/***************************/
/***** ATTRIBUTE FLAGS *****/
/***************************/
if n_desc & REFERENCED_DYNAMICALLY == 1:
// This bit marks the symbols that runtime APIs like `dlsym()` might look up by name.
// The `strip` tool preserves these symbols even during aggressive stripping.
if n_desc & N_DESC_DISCARDED == 1:
// This bit is reserved for the dynamic linker's internal use at runtime.
// Don't set this yourself.
if n_desc & N_WEAK_REF == 1:
// This symbol is a weak reference.
// If the dynamic linker cannot find a definition for this symbol, it sets the address of this symbol
// to `0` (i.e. `NULL`), instead of causing a link error.
// The static linker sets this symbol given the appropriate weak-linking flags.
if n_desc & N_WEAK_DEF == 1:
// This symbol is a weak definition.
// If the static linker or the dynamic linker finds another (non-weak) definition for this symbol,
// the weak definition is ignored.
// Only symbols in a coalesced section (like C++ template instantiations or inline functions that might
// appear in multiple object files) can be marked as a weak definition.
/***************************/
/***** LIBRARY ORDINAL *****/
/***************************/
/*
Only when two-level namespace binaries is enabled (when `MH_TWOLEVEL` flag is set in the Mach-O header),
`n_desc` 的 bit 8,9,10,11,12,13,14,15 构成一个 byte 表示 library ordinal (i.e. the position number or order
number of libraries)
- library ordinal `== 0` 表示 "the current image itself"
- library ordinal `1<=i<=254` 表示 "the $i^{th}$ dylib" (numbered according to the order of
`LC_LOAD_DYLIB` load commands in the binary)
- library ordinal `== 255` 表示 "find this symbol in the executable that loaded me, not in a dylib I load"
*/
[!NOTE] reference/definition distinction
The distinction exists at the binary/linker level, not the source language level (i.e. the distinction is not language-specific). Once any language compiles down to machine code in Mach-O format (on macOS/iOS), the symbol table must distinguish between:
- Symbols this binary provides (definitions)
- Symbols this binary needs from elsewhere (references)
255 and Plugins ScenarioNormally, the dependency flow is:
Executable program
↓ (loads and uses)
Dynamic library
The executable depends on the library.
With plugins, the dependency flow is reversed:
Executable program (host application)
↑ (plugin uses symbols from)
Plugin (loaded at runtime)
The plugin depends on the executable that loaded it.
Imagine a photo editing app with a plugin architecture:
PhotoApp (executable):
// Defines utility functions for plugins to use
void registerFilter(const char* name, FilterFunc func);
Image* getCurrentImage();
BlurPlugin.bundle (plugin):
// Uses functions from PhotoApp
void initPlugin() {
registerFilter("Gaussian Blur", applyBlur); // Calls function from host app
Image* img = getCurrentImage(); // Calls function from host app
}
When the BlurPlugin symbol table has symbols referencing registerFilter and getCurrentImage:
This allows plugins to call back into the host application that loaded them.
n_valueAn $8$-byte integer that contains the value of the symbol. The format of this value is different for each type of symbol table entry (as specified by the n_type field). For the N_SECT symbol type, n_value is the address of the symbol. See the description of the n_type field for information on other possible values.
strtab 紧跟在 symtab 后面。由于我们这里有两个 symbols (nsym == 2)，然后每个 nlist_64 是 16-bytes，所以 strtab 的起始位置在 688 + 16 * 2 == 720 offset.
strtab 的本质是一个 C-string 的 sequence. E.g.:
ᐅ xxd -d -s 720 vanilla.o
00000720: 005f 6d61 696e 005f 6100 0000 0000 0000 ._main._a..
| Offset | Content |
|---|---|
000002d0 |
\0 |
000002d1 |
_main\0 |
000002d7 |
_a\0 |
[!NOTE] strtab 第一个 entry almost always 是
\0这是个 convention so that (1) unnamed or anonymous symbols (which are rare) can have
n_strx == 0and (2) invalid or deleted symbols can haven_strx == 0as a special marker
在我们的 LC_SYMTAB 例子中，strsize == 16 其实是因为有 padding for alignment，因为理论上来说，一个 \0 加上一个 _main\0 再加上一个 _a\0 只占了 10-byte 的空间，但为了 alignment，这个 strtab 会被 pad 成：
| Offset | Content | Size |
|---|---|---|
000002d0 |
\0 |
1 |
000002d1 |
_main\0 |
6 |
000002d7 |
_a\0 |
3 |
000002d8 |
\0\0\0\0\0\0\0 |
6 |
[!NOTE] foreign keys to strtab
可以把
n_strx理解成 symtab 到 strtab 的一个 foreign key. 这个设计使得这两个 tables 都是 aligned, reading 的效率非常高
如果我们拿到 executable:
ᐅ clang vanilla.o -o vanilla.out
再去和 object file 对比会发现：
__LINKEDIT segment这个判断依据是：object file 中，LC_SYMTAB 的 symoff 和 stroff 和其他的 segment/section 没有重叠；而 executable 中的情况是：
Load command 3
cmd LC_SEGMENT_64
cmdsize 72
segname __LINKEDIT
vmaddr 0x0000000100008000
vmsize 0x0000000000004000
fileoff 32768
filesize 208 # __LINKEDIT 的 range 是 [32768, 32976)
... ...
Load command 6
cmd LC_SYMTAB
cmdsize 24
symoff 32896
nsyms 3 # symtab 的 range 是 [32896, 32944), inside __LINKEDIT
stroff 32944
strsize 32 # strtab 的 range 是 [32944, 32976), inside __LINKEDIT
]]>[!note]
__LINKEDITsegment typically contains no sections, unlike__TEXTand__DATAIt’s just a blob of raw linking metadata that other load commands (like
LC_SYMTAB,LC_DYSYMTAB,LC_DYLD_INFO) reference by providing offsets into it.也真是这个原因，我们用
otool没法查看__LINKEDIT
我们在 Mach-O Stitching #3: Load Commands > LC_DYSYMTAB 中已经详述。
// secondary.c
int shared_int = 42;
int shared_float = 100.0;
void shared_func() {}
// main.c
extern int shared_int;
extern float shared_float;
void shared_func();
int main() {
shared_int = 43;
shared_float = 101.0;
shared_float = 102.0;
shared_func();
shared_func();
shared_func();
return 0;
}
# ᐅ clang -O0 -c secondary.c -o secondary.o
ᐅ clang -O0 -c main.c -o main.o
# ᐅ clang -O0 main.o secondary.o -o main.out
这里是一个大的 static linking 的 experiment code，但演示 dysymtab 只用 main.o 就可以了。
查看 object file 的 symtab:
ᐅ objdump --syms main.o
main.o: file format mach-o-x86-64
SYMBOL TABLE:
0000000000000000 g 0f SECT 01 0000 [.text] _main
0000000000000000 g 01 UND 00 0000 _shared_float
0000000000000000 g 01 UND 00 0000 _shared_func
0000000000000000 g 01 UND 00 0000 _shared_int
查看 object file 的 dysymtab:
ᐅ ᐅ otool -l main.o | grep -B 1 -A 19 "LC_DYSYMTAB"
Load command 3
cmd LC_DYSYMTAB
cmdsize 80
ilocalsym 0 # starting from symtab[0]
nlocalsym 0 # there is 0 localsym
iextdefsym 0 # starting from symtab[0]
nextdefsym 1 # there is 1 extdefsym
# meaning symtab[0] == `_main` is external defined
iundefsym 1 # starting from symtab[1]
nundefsym 3 # there are 3 undefsyms
# meaning symtab[1:4] == [`_shared_float`, `_shared_func`, `_shared_int`] are undefined
... ...
[!NOTE] Symbol Grouping & Sorting
[!NOTE]
extdefmeans external & defined, not externally defined
- if
n_type & N_EXT == 1$\Rightarrow$ symbol is external- if
n_type & N_TYPE == N_ABS or N_INDR or N_SECT$\Rightarrow$ symbol is defined- if both of the above conditions are satisfied $\Rightarrow$ symbol is a
extdefsym
]]>[!NOTE]
_main与LC_MAIN
_main通常被视为extdef, 目的是为了让 OS 或者dyld能够从文件外部“看到”并跳转到这个函数。如果你把main设为static(虽然 C 标准不允许这样做)，linker 就找不到它，程序也就无法启动。
LC_MAIN中指定的 offset 就是_main在 executable 中的起始位置。
// secondary.c
int shared_int = 42;
int shared_float = 100.0;
void shared_func() {}
// main.c
extern int shared_int;
extern float shared_float;
void shared_func();
int main() {
shared_int = 43;
shared_float = 101.0;
shared_float = 102.0;
shared_func();
shared_func();
shared_func();
return 0;
}
ᐅ clang -O0 -c secondary.c -o secondary.o
ᐅ clang -O0 -c main.c -o main.o
ᐅ clang -O0 main.o secondary.o -o main.out
[!caution] 一般称为 “relocation entries” 而不是 “relocation table”
虽然当你说 “relocation table” 时，somehow 大家也能懂你说的是啥，但更常用的叫法是 “relocation entries”.
in object files:
reloff/nreloc 字段reloff 不在 section 自己的范围内LC_DYLD_INFO 或者 LC_DYLD_INFO_ONLYextreloff/nextrel 或者 locreloff/nlocrel 字段规定的范围内Mach-O Header
Load Commands
- Segment commands
- Section headers (with reloff/nreloc)
Section Data:
__text section data
__data section data
__const section data
...
Relocation Entries:
Relocations for __text
Relocations for __data
Relocations for __const
...
Symbol Table
String Table
in executables:
直接用 otool 查看的话：
ᐅ otool -r main.o # Display the relocation entries.
main.o:
Relocation information (__TEXT,__text) 8 entries
address pcrel length extern type scattered symbolnum/value
00000053 1 2 1 2 0 2
0000004c 1 2 1 2 0 2
00000045 1 2 1 2 0 2
0000003a 1 2 0 1 0 2
00000032 1 2 1 3 0 1
00000027 1 2 0 1 0 2
0000001f 1 2 1 3 0 1
00000012 1 2 1 3 0 3
Relocation information (__LD,__compact_unwind) 1 entries
address pcrel length extern type scattered symbolnum/value
00000000 0 3 0 0 0 1
有点难读，给 otool 加上 -v option 再看看：
ᐅ otool -rv main.o
main.o:
Relocation information (__TEXT,__text) 8 entries
address pcrel length extern type scattered symbolnum/value
00000053 True long True BRANCH False _shared_func
0000004c True long True BRANCH False _shared_func
00000045 True long True BRANCH False _shared_func
0000003a True long False SIGNED False 2 (__TEXT,__literal4)
00000032 True long True GOT_LD False _shared_float
00000027 True long False SIGNED False 2 (__TEXT,__literal4)
0000001f True long True GOT_LD False _shared_float
00000012 True long True GOT_LD False _shared_int
Relocation information (__LD,__compact_unwind) 1 entries
address pcrel length extern type scattered symbolnum/value
00000000 False quad False UNSIGND False 1 (__TEXT,__text)
[!NOTE] Float numbers like
101.0are stored in(__TEXT, __literal4)section for optimization
2 (__TEXT,__literal4)前面的2表示 offset $2$ in the section.但
43这样的int就不需要这么处理。原因是：float的 size 太大，直接塞到 assembly instruction 里面会导致 instruction 本身的 size 太大；而int就不会有这个问题。这算是个比较特殊的 reloc，我们这里就不深究了。我们这里专注于 symbols.
我们拿这条输出为例：
address pcrel length extern type scattered symbolnum/value
00000012 True long True GOT_LD False _shared_int
# 00000012 1 2 1 3 0 3
它的意思是：
address 指 section 内部的 offset，意思是 “在 section 的这个位置上有一个需要 relocation 的 symbol”
00000012 是 0x12 的意思pcrelis a flag indicating if the relocation is PC-relativelength represents the size of the symbol to be relocated
0 = byte, 1 = word, 2 = long, 3 = quadextern is a flag indicating if the symbol is externaltype: see <mach-o/x86_64/reloc.h>，比如：
X86_64_RELOC_UNSIGNED $\Rightarrow$ 绝对地址模式X86_64_RELOC_GOT_LOAD $\Rightarrow$ movq symbol@GOTPCREL(%rip), %rax 模式X86_64_RELOC_BRANCH $\Rightarrow$ call/jmp 指令的分支目标scattered is a flag indicating if the relocation is scattered (rarely used)
address 即使溢出也表示不到一个合法的 section offset，此时就要用到 scattered relocation 技术symbolnum/value:
extern == True, this is the symbol indexextern == False, this is the section ordinal我们这里以 (__TEXT, __text) section 的 relocs 为例 (注意其他的 section 也可能会有 relocs):
otool -l 查看 section 的 LC_SEGMENT_64 中的 reloff/nreloc 字段xxd -s 定位到 object file 的 reloff 位置还是以这条 reloc 为例：
address pcrel length extern type scattered symbolnum/value
00000012 True long True GOT_LD False _shared_int
# 00000012 1 2 1 3 0 3
它对应的 binary raw data 是：
# -d: use decimal addresses
# -e: use little endian
# 2000 is the `reloff` of `(__TEXT, __text)`
ᐅ xxd -s 2000 -d -e main.o
00002000: 00000053 2d000002 0000004c 2d000002
00002016: 00000045 2d000002 0000003a 15000002
00002032: 00000032 3d000001 00000027 15000002
00002048: 0000001f 3d000001 00000012 3d000003
#---------------# <- reloc for `_shared_int` at 0x00000012
如果从 LSB (least significant bit) 开始，这 8-byte 可以拆分成这么一个结构：
struct relocation_info {
uint32_t r_symbolnum:24, // bit 0-23
r_pcrel:1, // bit 24
r_length:2, // bit 25-26
r_extern:1, // bit 27
r_type:4; // bit 28-31
int32_t r_address; // bit 32-63
};
于是有：
| Fields | r_address |
r_symbolnum |
|
|---|---|---|---|
| Hex. Values | 0x00000012 |
0x3d |
0x000003 |
而 0x3d == 0b 0011 1101，所以：
| Fields | r_symbolnum |
r_extern |
r_length |
r_pcrel |
|---|---|---|---|---|
| Bin. Values | 0011 |
1 |
10 |
1 |
| Dec. Values | 3 |
1 |
2 |
1 |
你会发现还差一个 scattered flag 在 binary raw data 中没有体现，这是因为这个 flag 可以用 address 推断：
MSB(r_address) == 0 (address 的 most significant bit，也就是 reloc 的 bit $63$)MSB(r_address) == 1这么算下来，reloc 的 binary raw data 与 otool -r 的输出是一致的。
Relocs 需要配合 assembly code 一起理解，所以这里我们要先搞清楚 “哪些 assembly instructions 对应了哪个 C Statement” 这个问题。
其实有很多办法，但下面这两个方法结合起来用会更方便理解。
.s assembly”)ᐅ clang -S -O0 main.c -fverbose-asm -o main.s
得到的 assembly 是：
.section __TEXT,__text,regular,pure_instructions
.build_version macos, 13, 0
.section __TEXT,__literal4,4byte_literals
.p2align 2, 0x0 ## -- Begin function main
LCPI0_0:
.long 0x42cc0000 ## float 102
LCPI0_1:
.long 0x42ca0000 ## float 101
.section __TEXT,__text,regular,pure_instructions
.globl _main
.p2align 4, 0x90
_main: ## @main
.cfi_startproc
## %bb.0:
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq %rsp, %rbp
.cfi_def_cfa_register %rbp
subq $16, %rsp
movl $0, -4(%rbp)
movq _shared_int@GOTPCREL(%rip), %rax
movl $43, (%rax)
movq _shared_float@GOTPCREL(%rip), %rax
movss LCPI0_1(%rip), %xmm0 ## xmm0 = [1.01E+2,0.0E+0,0.0E+0,0.0E+0]
movss %xmm0, (%rax)
movq _shared_float@GOTPCREL(%rip), %rax
movss LCPI0_0(%rip), %xmm0 ## xmm0 = [1.02E+2,0.0E+0,0.0E+0,0.0E+0]
movss %xmm0, (%rax)
movb $0, %al
callq _shared_func
movb $0, %al
callq _shared_func
movb $0, %al
callq _shared_func
xorl %eax, %eax
addq $16, %rsp
popq %rbp
retq
.cfi_endproc
## -- End function
.subsections_via_symbols
注意 register 的名称：
%rbp: Register of Base Pointer (points to the base of current stack frame)%rsp: Register of Stack Pointer (points to the top of the stack; a.k.a. $SP$)%rax: Register of Accumulator (this is a general purpose register)%rip: Register of Instruction Pointer (points to the next instruction; a.k.a. program counter or $PC$)注意 register 的逻辑：
(%rxx) 表示 use the value stored in %rxx as an address注意这几个 move 命令的区别：
movq: Move a Quadword (8-byte)movl: Move a Longword (4-byte)movess: Move a Scalar Single-precision (4-byte)movb: Move a Byte (1-byte).o assembly”)# -g: 编译时附带 debug 信息
ᐅ clang -g -O0 -c main.c -o main.o
# -S: 反汇编时显示源码
ᐅ llvm-objdump -S main.o
得到的结果是：
main.o: file format mach-o 64-bit x86-64
Disassembly of section __TEXT,__text:
0000000000000000 <_main>:
; int main() {
0: 55 pushq %rbp
1: 48 89 e5 movq %rsp, %rbp
4: 48 83 ec 10 subq $0x10, %rsp
8: c7 45 fc 00 00 00 00 movl $0x0, -0x4(%rbp)
; shared_int = 43;
f: 48 8b 05 00 00 00 00 movq (%rip), %rax ## 0x16 <_main+0x16>
16: c7 00 2b 00 00 00 movl $0x2b, (%rax)
; shared_float = 101.0;
1c: 48 8b 05 00 00 00 00 movq (%rip), %rax ## 0x23 <_main+0x23>
23: f3 0f 10 05 39 00 00 00 movss 0x39(%rip), %xmm0 ## 0x64 <_main+0x64>
2b: f3 0f 11 00 movss %xmm0, (%rax)
; shared_float = 102.0;
2f: 48 8b 05 00 00 00 00 movq (%rip), %rax ## 0x36 <_main+0x36>
36: f3 0f 10 05 22 00 00 00 movss 0x22(%rip), %xmm0 ## 0x60 <_main+0x60>
3e: f3 0f 11 00 movss %xmm0, (%rax)
; shared_func();
42: b0 00 movb $0x0, %al
44: e8 00 00 00 00 callq 0x49 <_main+0x49>
; shared_func();
49: b0 00 movb $0x0, %al
4b: e8 00 00 00 00 callq 0x50 <_main+0x50>
; shared_func();
50: b0 00 movb $0x0, %al
52: e8 00 00 00 00 callq 0x57 <_main+0x57>
; return 0;
57: 31 c0 xorl %eax, %eax
59: 48 83 c4 10 addq $0x10, %rsp
5d: 5d popq %rbp
5e: c3
[!caution] Relocs are a TODO list
注意这个逻辑关系：
- relocs 是 assembler 生成的，它相当于是一个 TODO list
- relocation 是 static-linker 执行的，它在执行的时候要参考 relocs
所以我认为 relocs 叫 Future Relocation Entries 会更好理解
[!caution] dynamic linking 也会有 “relocation” 操作，但执行逻辑与 static linker 不同，它也不需要 relocs
dynamic linker 参考的是 rebasing 和 binding 信息，这些信息的格式与 relocs 不同
[!NOTE] 用词
现在一般的用法是：
- relocation 专指 “static linker 的 relocation”
- “dynamic linker 的 relocation” 用 fixup 表示
我们还是以这条 reloc 为例：
address pcrel length extern type scattered symbolnum/value
00000012 True long True GOT_LD False _shared_int
它针对的是这句 instruction:
; shared_int = 43;
f: 48 8b 05 00 00 00 00 movq (%rip), %rax
# addr: 0f 10 11 12 13 14 15
## <- reloc <address == 0x12>
#---------# <- reloc <length == long == 4-byte>
16: c7 00 2b 00 00 00 movl $0x2b, (%rax)
那么这条 reloc 的意思就是：0x0f 这句 instruction 的后面 4 bytes (对应 symbol _shared_int) 需要 patch.
我们这一节的目的是拆解 48 8b 05 00 00 00 00.
首先完整的 x86 指令编码方案可以表示为：
┌────────┬────────┬────────┬─────┬──────────────┬───────────┐
│ Prefix │ Opcode │ ModR/M │ SIB │ Displacement │ Immediate │
└────────┴────────┴────────┴─────┴──────────────┴───────────┘
可选 必需 可选 可选 可选 可选
下面我们讨论这些 fields 的意义。
# Register Addressing (寄存器寻址)
# 不访问内存，完全在 CPU 内部完成
movq %rbx, %rax # 将 rbx 的值复制到 rax
# Immediate Addressing (立即数寻址)
# 常用于给变量赋初值
# 吐槽：这里根本没有 "寻址" 动作，你的 immediate 直接就在 instruction 内部，寻什么寻？
movq $100, %rax # 将数值 100 放入 rax
# Register Indirect Addressing (寄存器间接寻址)
# 类似于 C 语言中的 dereferencing
movq (%rbx), %rax # 类似于 rax = *rbx
# Displacement Addressing (偏移量寻址)
# 这是函数局部变量访问的标准方式
movl -8(%rbp), %eax # 类似于 eax = *(%rbp - 8)
# %rbp 是 stack top
# SIB Addressing (比例索引寻址)
# final_addr == base + index * scale + displacement
# 吐槽：虽然名字 SIB 只包括了 Scale/Index/Base，但是 displacement 是存在的
# 这是访问数组元素的标准方式
movl 8(%rbx, %rcx, 4), %eax # 类似于 eax = *(%rbx + %rcx * 4 + 8)
# RIP-Relative Addressing (RIP 相对寻址)
# 访问全局变量的标准方式
movq _my_global_var(%rip), %rax # 访问全局变量 _my_global_var，它的地址由 RIP 相对计算
[!faq] 是否存在 “immediate indirect addressing”? 形如
rax = *(100)where100is an address否。你大可以把 immediate 存入某个 register，然后再 register indirect addressing.
[!faq] Register Indirect Addressing 和 Displacement Addressing 是 SIB Addressing 的特殊形式吗？
逻辑上可以这么认为。但是区分开来是因为它们的应用场景显著不同。
[!faq] RIP-Relative Addressing 是 SIB Addressing 的特殊形式吗？
逻辑上有相似之处，但底层编码差异很大。原因是：
%rip在 CPU 架构中是非常特殊的寄存器，它由分支预测器和取指单元控制，并不像%rax、%rbx那样位于通用寄存器组 (GPRs) 中- 而 SIB 的设计初衷是使用 GPRs
- 如果你硬要把
%rip引入 SIB 计算电路中，需要额外的硬件连线，这会增加芯片设计的复杂度
[!faq] SIB Addressing 如何读取数据元素？
假设你有一个
struct的 array，每个struct的 size 是 8-byte，然后要访问的 fieldfoo在struct内的 offset 是 4-byte，当前 index 是i，那么array[i].foo就能编译成：4(%rax, %rbx, 8)where:
%rax == array即 array 的首地址%rbx == i
$\operatorname{ModR/M}$ 的 general form 是：
┌───────┬────────┬────────┐
│ Mod │ Reg │ R/M │
└───────┴────────┴────────┘
2-bit 3-bit 3-bit
把它放回 x86 指令编码方案中有：
┌────────┬────────┬────────┬─────┬──────────────┬───────────┐
│ Prefix │ Opcode │ ModR/M │ SIB │ Displacement │ Immediate │
└────────┴────────┴────────┴─────┴──────────────┴───────────┘
______/ \_______
/ \
┌───────┬────────┬────────┐
│ Mod │ Reg │ R/M │
└───────┴────────┴────────┘
考虑 op operand1 operand2 这个 general form：
op 自然是被 encode 到了 $\overline{\operatorname{Opcode}}$operand1 一定会被 encode 到 $\overline{\operatorname{Reg}}$operand2 就要靠 $\overline{\operatorname{Mod}}$ 和 $\overline{\operatorname{R/M}}$ 一起决定了| $\overline{\operatorname{Mod}}$ | $\overline{\operatorname{R/M}}$ | Addressing | Remark |
|---|---|---|---|
11 |
此时必定为 register 编号 | %reg |
|
01 |
只要不是 100，则必定为 register 编号 |
disp8(%reg) |
默认 $\overline{\operatorname{SIB}}$ 为空，$\overline{\operatorname{R/M}}$ 后面的 1-byte 为 $\overline{\operatorname{Displacement}}$ |
10 |
只要不是 100，则必定为 register 编号 |
disp32(%reg) |
默认 $\overline{operatorname{SIB}}$ 为空，$\overline{\operatorname{R/M}}$ 后面的 4-byte 为 $\overline{\operatorname{Displacement}}$ |
00 |
只要不是 100 或者 101 |
(%reg) |
|
00 |
101 |
disp32(%rip) |
RIP-Relative addressing |
00/01/10 |
100 |
对应的 SIB addressing | 比如 Mod == 10; R/M == 100 就是 disp32(%reg) 的 SIB 形式 |
那么问题来了：是否存在编号为 100 的 register? 如果存在的话，假设它叫 %reg，我如何表示 disp8(%reg)?
首先存在编号为 100 的 register，但情况有点复杂。
在 macOS 常见的 Intel x86-64 架构中，operand size 对应着不同的数据类型：
| operand size | 汇编后缀 (AT&T) | 寄存器示例 | C 语言对应类型 |
|---|---|---|---|
| 8-bit | b (byte) |
%al, %bl |
char |
| 16-bit | w (word) |
%ax, %bx |
short |
| 32-bit | l (long) |
%eax, %ebx |
int |
| 64-bit | q (quadword) |
%rax, %rbx |
long long 或指针 |
r0 ~ r7r8 ~ r15；但 Intel 不想推翻重来，于是就在原有指令前面塞一个 [[#$\overline{\operatorname{REX}}$ Prefix]]，相当于是打了个补丁100 的 register 可能是 r4 (因为 0b 100 == 4)，也可能是 r12 (0b 100 加 prefix 构成 0b 1100 == 12)[!info] 32-bit operand size 下，
r4即是%esp
那现在假设我们要 disp8(%esp)，它就只能用 SIB 的形式来写，算是一种 hack：
Mod == 01R/M == 100SIB 的 Base == 100disp8(base=100, index=0, scale=1) 而不是 disp8(reg=100)$\overline{\operatorname{SIB}}$ 的 general form 是：
┌───────┬─────────┬────────┐
│ Scale │ Index │ Base │
└───────┴─────────┴────────┘
2-bit 3-bit 3-bit
00/01/10/11，表示具体的 scale 值 1/2/4/8[!caution] assembly 中 SIB addressing 的 instruction 一定是写 “具体的 scale 值”，即一定是
(base, index, scale = 1/2/4/8)形式只是这个 instruction 被 encode 成 binary 时，这个 “具体的 scale 值” 会被 encode 成 $\overline{\operatorname{Scale}}$ 的 2-bit
[!faq] 如果
scale > 8，该怎么办？比如说我想实现
(base, index, scale = 12)，就只能曲线救国：
- 先把
index * 12存入一个临时 registertemp- 然后把
(base, index, scale = 12)改写成(base, temp, scale = 1)
放回 x86 指令编码方案中有：
┌───────┬─────────┬────────┐
│ Scale │ Index │ Base │
└───────┴─────────┴────────┘
\ /
–––––––– –––––––––
\ /
┌────────┬────────┬────────┬─────┬──────────────┬───────────┐
│ Prefix │ Opcode │ ModR/M │ SIB │ Displacement │ Immediate │
└────────┴────────┴────────┴─────┴──────────────┴───────────┘
______/ \_______
/ \
┌───────┬────────┬────────┐
│ Mod │ Reg │ R/M │
└───────┴────────┴────────┘
我们回到指令的编码 48 8b 05 00 00 00 00.
0x48 == 0b 0100 1000 is the REX (REgister eXtension; X86-64 specific) prefix (to the Opcode).
[!caution] 注意
0x48这 8-bit 的一段的名称就叫 REX然后它本质上是个 prefix, 所以也总被称为 “REX prefix” (有点类似 “a Camry sedan” 这样的构词法)，并不是 “prefix to REX” 的意思。
[!caution] 还有其他类型的 prefix，不止 REX 这一种
把这 8-bit 拆分一下有：
0100 是 $\overline{\operatorname{REX}}$ 的固定标志位，即形如 0100 XXXX 的都是 REX prefix1000 是 4 个 flags, 从 MSB 到 LSB 分别是:
W == 1 $\Rightarrow$ width flag
W == 0 表示 32-bit operand size (默认)W == 1 表示 64-bit operand size (扩展)R == 0 $\Rightarrow$ register flag, 用于强化 $\overline{\operatorname{ModR/M}} \rhd \overline{\operatorname{Reg}}$ 所表示的 register 范围X == 0$\Rightarrow$ index flag, 用于强化 $\overline{\operatorname{SIB}} \rhd \overline{\operatorname{Index}}$ 所表示的 register 范围B == 0$\Rightarrow$ base flag, 用于强化 $\overline{\operatorname{ModR/M}} \rhd \overline{\operatorname{R/M}}$、或者 $\overline{\operatorname{SIB}} \rhd \overline{\operatorname{Base}}$ 所表示的 register 范围
0 表示你 3-bit 的 register 编号对应 r0 ~ r71 表示你 3-bit 的 register 编号对应 r8 ~ r15 REX.X REX.B
| |
* *
┌───────┬─────────┬────────┐
│ Scale │ Index │ Base │
└───────┴─────────┴────────┘
\ /
–––––––– –––––––––
\ /
┌────────┬────────┬────────┬─────┬──────────────┬───────────┐
│ REX │ Opcode │ ModR/M │ SIB │ Displacement │ Immediate │
└────────┴────────┴────────┴─────┴──────────────┴───────────┘
| ______/ \_______
| / \
┌────────┐┌───────┬────────┬────────┐
│0100WRXB││ Mod │ Reg │ R/M │
└────────┘└───────┴────────┴────────┘
* *
| |
REX.R REX.B
shared_int = 43; 这一句的 assembly 的逻辑是：
rax = &(shared_int);
*rax = 43;
实际的 .o assembly 是：
; shared_int = 43;
f: 48 8b 05 00 00 00 00 movq (%rip), %rax # rax = *(base=rip, displacement=0)
# addr: 0f 10 11 12 13 14 15
## <- reloc <address == 0x12>
#---------# <- reloc <length == long == 4-byte>
16: c7 00 2b 00 00 00 movl $0x2b, (%rax) # *rax = 43
具体到这个 instruction 的成分：
# movq (%rip), %rax
# 48 8b 05 00 00 00 00
0x48 == 0b 0100 1000 # REX.W == 1
0x8b # Opcode for MOV
# 因为 REX.W == 1, 所以具体是 MOVQ
0x05 == 0b 0000 0101 # Mod == 00
# Reg == 000, 对应 %rax
# R/M == 101, 对应 RIP-Relative addressing, 即 disp32(%rip)
0x00 00 00 00 # Displacement == 0
所以 reloc 的逻辑是：
// .o assembly logic
int d_shared_int = 0; // displacement for shared_int
register rax = *(base=rip, displacement=d_shared_int); // movq (%rip), %rax
// rax is supposed to point to shared_int
*rax = 43;
// reloc logic
reloc.address = &d_shared_int;
reloc.type = "GOT_LD";
// ...
mark_for_alteration(address=reloc.address, type=reloc.type, ...);
注意这条 reloc 只是指定了 去 GOT 中找一条 entry，它记录了 shared_int 的地址，但是注意一个问题：object file 中并没有 GOT. 所以 具体定位到那一条 GOT entry 是 static linker 的工作，具体说来：
reloc.address 与对应的 GOT entry 之间的 offset (注意还有 %rip 要参与运算)
displacementdisplacement 写入 reloc.address(__TEXT,__text) in object file (__DATA, .data/.bss) in executable
+--------------------+ +--------------------------+
| Instruction: | | External _shared_int |
| movq (%rip), %rax | | Address: 0x3000 |
+---------+----------+ | Value: 42 |
| +--------------------------+
| ^
v |
(.got) in executable |
+-------------------------+ |
| [Entry for _shared_int] | |
| Content: 0x3000 | ------------------------+
+-------------------------+
// secondary.c
int get_answer() {
return 42;
}
int another_answer = 100;
// main.c
// Forward declaration of a function
extern int get_answer();
// `extern` is often considered redundant there,
// because compiler assumes any function without a "body" `{}` is external,
// i.e. function names have external linkage by default.
// int get_anwser();
// Forward declaration of a variable
// `extern` is necessary here
extern int another_answer;
// Without `extern`, it becomes a tenative definition.
// More on that later.
// int another_answer;
int main() {
return get_answer() + another_answer;
}
Step 1 - Preprocessing (C $\Rightarrow$ C)
ᐅ gcc -E main.c -o main.i
ᐅ gcc -E secondary.c -o secondary.i
Step 2 - Compilation (C $\Rightarrow$ Assembly)
ᐅ gcc -S main.i -o main.s
ᐅ gcc -S secondary.i -o secondary.s
# ᐅ or
# ᐅ cc1 main.c -o main.s
# ᐅ cc1 secondary.c -o secondary.s
[!NOTE]
cc1包含了 preprocessing 步骤，所以可以直接处理.c
Step 3 - Assembling (Assembly $\Rightarrow$ Relocatable Object/Binary)
ᐅ gcc -c main.s -o main.o
ᐅ gcc -c secondary.s -o secondary.o
# or
# ᐅ as main.s -o main.o
# ᐅ as secondary.s -o secondary.o
Or directly C $\Rightarrow$ Relocatable Object/Binary:
ᐅ gcc -c main.c -o main.o
ᐅ gcc -c secondary.c -o secondary.o
Relocatable Object/Binary $\Rightarrow$ Executable Object/Binary
Method 1: use the object file secondary.o directly:
ᐅ gcc main.o secondary.o -o main_static.out
Method 2: create a static library archive from secondary.o:
ᐅ ar rcs secondary.a secondary.o
# link like above
ᐅ gcc main.o secondary.a -o main_static.out
ar is an archive tool, just like zip or tar
r: replace/add files to archivec: create archive if it doesn’t exists: create an index (symbol table) for faster linking.a 并不是 Mach-O format, 它也不是 object file, 它单纯就是个能被 link 的压缩包格式[!NOTE] 如果你有很多个 dependencies，那么 static library archive 无疑是工程上的 best practice.
Method: create a dynamic lib from secondary.o:
ᐅ gcc -dynamiclib secondary.o -o secondary.dylib
ᐅ gcc main.o secondary.dylib -o main_dynamic.out
[!NOTE]
.dylibon macOS is equivalent to.soon Linux.
[!NOTE]
.dylib是 Mach-O format
[!NOTE]
.dylib不是 object file, 因为 “object”, “executable”, “dynamic lib” 是三种平行的文件类型
gcc -L -l我们也可以这么做 static linking:
ᐅ ar rcs libsecondary.a secondary.o
ᐅ gcc main.o -L. -lsecondary -o main_static.out
也可以这么做 dynamic linking:
ᐅ gcc -dynamiclib secondary.o -o libsecondary.dylib
ᐅ gcc main.o -L. -lsecondary -o main_dynamic.out
这里 gcc -L -l 有特定的 search pattern:
-L. 指定 search directory 为 . (current folder)lib 开头，所以 -lsecondary 实际指定的是 libsecondary 这个 name
libsecondary 这个名字此时就有一个问题：如果我们同时有 libsecondary.a 和 libsecondary.dylib, -lsecondary 如何确定是 static linking 还是 dynamic linking? 它其实有一个规则：
libsecondary.dylib 做 dynamic linkingdylib 就找 libsecondary.a 做 static linkinglibsecondary.o如果我们同时有 libsecondary.a 和 libsecondary.dylib, 我们可以用 option -static force 执行 static linking:
ᐅ gcc main.o -L. -static -lsecondary -o main_static.out
ᐅ otool -L main_static.out
main_static.out:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1)
main_static.out does NOT need secondary.dylib nor secnondary.o because it’s already wrapped inside the binary[!info]
libSystem.B.dylibplays the same role on macOS thatglibc.soplays on Linux (as the C standard library)它俩实现上略有不同：
glibc.so是一个 monolith lib;libSystem.B.dylib是一个 facade to multiple libs.
ᐅ otool -L main_dynamic.out
main_dynamic.out:
secondary.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1)
main_dynamic.out knows it needs the external secondary.dylibᐅ nm main_static.out
0000000100000000 T __mh_execute_header
0000000100004000 D _another_answer # linked variable
0000000100003f90 T _get_answer # linked function
0000000100003f60 T _main
ᐅ nm main_dynamic.out
0000000100000000 T __mh_execute_header
U _another_answer # undefined variable
U _get_answer # undefined function
0000000100003f70 T _main
T: the symbol is in (__TEXT, __text)D: the symbol is in (__DATA, __data) (initialized data)U: the symbol is undefined