字节码与二进制格式（ELF/WASM/class）

• 控制流指令 br/if
• 内存访问指令
• 函数调用 call

WebAssembly MVP 指令集是结构化、类型化的：控制流指令 br、br_if、if、loop 通过明确的块结构表达分支与循环；内存访问指令 load/store 通过内存地址与偏移访问线性内存；call、call_indirect 调用函数；算术与比较指令处理数值。所有指令都经类型检查，无未定义行为。MVP 指令集定义紧凑、可验证，是 WASM 执行的核心。

本题考察 WASM 指令集。核心是"结构化控制流 + 类型化内存访问 + 调用"。作答时说明 MVP 指令的组织与验证。

• WASI Preview2 的模块
• 标准接口
• 可移植性

WASI Preview2 提供标准化的系统接口模块，涵盖 HTTP、Sockets、Storage、Filesystem、IO、Clocks、Random 等，让 WASM 应用在沙箱内访问宿主能力。其工程价值是标准化接口保证跨运行时（wasmtime、wasmer 等）可移植，且基于 component model 实现模块化与能力隔离。WASI 让 WASM 从浏览器走向通用服务端。

本题考察 WASI Preview2。核心是"标准接口 + 跨运行时可移植 + 能力隔离"。作答时说明其工程价值。

• dexopt 的优化
• dex2oat 的 AOT
• 安装与运行性能

.dex 是 Android 的 Dalvik 字节码文件。Android 5+ 的 ART 运行时用 dex2oat 在安装时把 dex 编译为本地机器码（AOT），减少运行时解释开销，提升启动与执行性能；dexopt 做优化的 dex 校验与内联。AOT 编译的工程价值是加快应用启动、减少运行时 JIT 负担，但增加安装体积与时间。ART 也结合 JIT 动态优化。

本题考察 ART AOT。核心是"dex2oat 安装时 AOT 编译提升性能"。作答时说明 AOT 的收益与代价。

• auxiliary vector 的内容
• 传递机制
• 工程用途

auxiliary vector（auxv）是加载器在程序启动时通过栈传给程序的键值数组，包含页面大小、处理器特征、AT_SYSINFO_EHDR（VDSO 地址）、AT_PHDR、AT_ENTRY 等信息。其工程价值是让程序无需系统调用即可获取启动环境信息，供动态链接器与运行时使用。auxv 是程序启动时加载器与应用之间的关键接口。

本题考察 auxv。核心是"栈传递启动环境信息 + 免系统调用"。作答时说明其传递机制与用途。

• trace_pipe 的读取
• splice/read
• 流式读取

trace_pipe 提供 ftrace 的流式追踪输出，用户可经 read 或 splice 读取，splice 支持零拷贝地把数据送入管道或 socket，减少拷贝开销。其工程应用是构建实时追踪采集与转发，对高吞吐追踪数据高效消费。相比 trace 文件，trace_pipe 是流式消费，适合持续监控。

本题考察 trace_pipe。核心是"流式读取 + splice 零拷贝"。作答时说明其高效消费追踪数据。

• Go 特有 section
• .gosymtab/.gopclntab
• 运行时与调试

Go 二进制在 ELF 中包含 .gosymtab（Go 符号表）与 .gopclntab（PC 到函数行号的映射表），支撑 Go 运行时的 panic 回溯、goroutine 栈与性能分析；.text 放代码，.data/.bss 放数据。.gopclntab 让 Go 能高效实现栈回溯与采样，.gosymtab 供调试。这些 section 是 Go 运行时与工具链的工程基础。

本题考察 Go ELF section。核心是"Go 特有符号/PC 映射表支撑运行时"。作答时说明其工程价值。

• Full RELRO 的机制
• -z now 立即绑定
• GOT 只读

Full RELRO 通过 -z relro -z now 组合：-z now 让所有函数在加载时立即绑定（禁用 lazy binding），GOT 各项在启动时全部解析；-z relro 把重定位后只读的段（含 GOT）标记为只读。这样 GOT 在初始化后变只读，攻击者无法通过越界写覆写 GOT 劫持函数指针，防御 GOT overwrite 攻击。代价是启动时多解析全部符号。

本题考察 Full RELRO。核心是"立即绑定 + 只读段保护 GOT"。作答时说明防御机制与代价。

• Delay Import Descriptor
• 延迟绑定
• 启动优化

DIDT（Delay Import Descriptor）实现 PE/COFF 的延迟导入，函数首次调用时才加载对应 DLL 并解析地址，类似 ELF 的 lazy binding。其工程价值是减少启动时加载与解析的 DLL 数量，加快启动速度，仅在实际用到时才加载。DIDT 让 Windows 程序按需加载依赖，优化启动。

本题考察延迟导入。核心是"首次调用才加载 DLL + 启动优化"。作答时说明 DIDT 的价值。

• Fat binary 多架构
• 单文件分发
• 兼容性

Mach-O Universal/Fat binary 用单个文件封装 x86_64 与 arm64 等多架构切片，加载时按当前架构选择。工程价值是单文件分发覆盖多架构设备，便于 app store 与分发，同时兼容不同硬件。代价是体积增大。Fat binary 让跨架构发布简化。

本题考察 Fat binary。核心是"单文件多架构 + 简化分发"。作答时说明其价值与代价。

• 各 symbol 类型
• 符号语义
• 链接与调试

ELF 符号类型（st_info 的 type 字段）标识符号性质：FUNC 是函数，OBJECT 是数据对象，NOTYPE 是未指定类型，FILE 是源文件符号，SECTION 是节符号。这些类型帮助链接器、调试器与工具理解符号语义，正确处理符号绑定与重定位。符号类型是链接与调试的基础信息。

本题考察 ELF 符号类型。核心是"类型标识符号性质 + 支撑链接调试"。作答时说明各类型含义。

• .gnu.version 的结构
• 版本节点
• 多版本共存

.gnu.version 及相关节实现符号版本化：每个导出符号关联版本标签，.gnu.version_d 定义版本定义，.gnu.version_r 定义版本引用。链接器按符号版本匹配依赖，旧二进制引用旧版本、新二进制引用新版本，使同一库内多版本符号共存。这支撑库的 ABI 演进与向后兼容。

本题考察符号版本化。核心是"版本标签让多版本共存 + 支持兼容"。作答时说明 .gnu.version 机制。

• WASM 验证器
• JVM 边界检查
• 安全保证差异

WASM 验证器在加载时对模块做静态类型检查，验证函数类型、控制流结构、内存访问合法性，保证运行期无需动态边界检查；JVM 的 verifier 校验字节码类型安全，但数组访问等仍需运行时边界检查。WASM 通过严格静态验证降低运行时检查，二者都以类型安全保证内存安全，但策略不同。

本题考察 WASM 与 JVM 验证。核心是"静态验证 vs 运行时检查"。作答时说明两者安全保证差异。

• LdrLoadDll 的加载
• 延迟绑定
• Windows 加载器机制

Windows 的 PE 加载器由 ntdll 的 LdrLoadDll 等函数驱动，负责加载 DLL、解析导入表、处理重定位。延迟绑定通过 Delay Import Descriptor 在首次调用时才 LdrLoadDll 加载对应 DLL 并填充导入地址表。这减少启动时加载的 DLL 数量，加快启动。Windows 加载器与 ELF 的 dlopen 类似但机制不同。

本题考察 Windows 加载器。核心是"LdrLoadDll 加载 + 延迟绑定"。作答时说明 Windows 加载机制。

• Partial RELRO
• Full RELRO
• BIND_NOW 关系

Partial RELRO 把 GOT 中只读部分（含 .got 表头）置为只读，但可写部分仍在前；Full RELRO 结合 -z now（BIND_NOW）使所有 GOT 在启动时绑定，并把整个 GOT 置为只读，彻底防止 GOT 覆写。BIND_NOW 是 Full RELRO 的前提，因为 lazy binding 需要可写 GOT。二者关系：now 禁用 lazy binding，relro 才可全只读。

本题考察 RELRO。核心是"Partial vs Full + BIND_NOW 的关系"。作答时说明 Full RELRO 依赖 now 绑定。

• WIT 接口定义
• Component Model
• 跨语言互操作

WIT（WebAssembly Interface Types）是 Component Model 的接口定义语言，描述组件间的类型与函数签名，结合 wit-bindgen 生成跨语言绑定。其工程价值是让组件（在不同语言编写）通过标准化接口互操作与组合，支持 wasmtime、wasmCloud 等的模块化分解与复用。WIT 让 WASM 生态具备可组合的组件化能力。

本题考察 WIT。核心是"接口定义 + 跨语言组件互操作"。作答时说明其模块化价值。

• SIMD 的向量计算
• Threads 的共享内存
• Reference Types

WASM SIMD 扩展提供 128 位向量指令，加速多媒体与数值计算；Threads 扩展引入共享内存与原子操作，支持多线程；Reference Types 引入引用类型（externref、funcref），支持 GC 与宿主对象引用。这些扩展让 WASM 从简单沙箱扩展到高性能并行与交互场景，提升适用性。

本题考察 WASM 扩展。核心是"SIMD/Threads/Reference 扩展能力"。作答时说明各扩展的作用。

• WASM GC 的自动管理
• 相对手动分配
• 语言支持

WASM GC proposal 为 WASM 引入高级类型与自动垃圾回收，支持面向对象结构与语言（如 Java、C#）高效编译，无需手动管理内存。相对手动分配（malloc/free），GC 减少内存管理错误、简化跨语言对象互操作。其工程价值是让 GC 语言与复杂对象结构在 WASM 高效运行。

本题考察 WASM GC。核心是"自动 GC 减少手动分配负担"。作答时说明其对 GC 语言的价值。

• 各 attribute 的作用
• Code 的字节码
• 调试信息

.class 的 attributes 提供附加信息：Code 存放方法字节码与异常表，ConstantValue 表示常量字段初值，LineNumberTable 映射字节码到源码行号，LocalVariableTable 描述局部变量名与类型。它们支撑 JVM 执行（Code）、常量初始化（ConstantValue）与调试（行号/变量），是字节码执行与调试的基础。

本题考察 .class attributes。核心是"各 attribute 支撑执行与调试"。作答时说明其作用。

• major.minor 版本
• 对应 Java 版本
• 兼容性

.class 文件的 major.minor version 标识字节码版本，如 major 55 对应 Java 11、61 对应 Java 17、65 对应 Java 21。JVM 据版本决定是否接受与执行该类文件，版本过高则拒绝（UnsupportedClassVersionError）。其工程价值是显式管理 Java 语言与字节码的兼容边界，让工具链清晰判断可运行版本。

本题考察 class 版本。核心是"版本标识兼容边界"。作答时说明版本与 Java 的对应及兼容作用。

• JVM TI 的接口
• JDWP 协议
• 调试器实现

JVM TI（Tool Interface）是 JVM 的本地调试接口，支持设置断点、监听线程/类事件、获取栈与内存信息。JDWP 是调试协议，把调试器命令传输给 JVM，JVM 通过 JVM TI 实现底层操作。调试器（如 IDE）经 JDWP 连接 JVM，JVM TI 提供能力，二者配合实现远程调试。这是 Java 调试架构的基础。

本题考察 JVM TI/JDWP。核心是"JVM TI 提供能力、JDWP 传输协议"。作答时说明调试架构。

• D8 的 dex 转换
• R8 的优化
• tree shaking

D8 是把 Java bytecode 转换为 Android dex 的 dexer（替代旧 DX），生成更优化的 dex；R8 是优化器，在 D8 基础上做 tree shaking（删除未用代码）、内联、资源缩减等，减小 APK 体积并提升性能。二者结合在构建时产出精简、高效的 dex，是 Android 构建优化的关键。

本题考察 D8/R8。核心是"dex 转换 + tree shaking 优化体积"。作答时说明其构建价值。

• mterp 的解释器
• ART JIT 的按需编译
• AOT 与安装包

ART 的 mterp 是解释器，JIT 按需编译热点方法为本地码，AOT 在安装时（dex2oat）预编译为本地码。工程边界：AOT 提升启动与运行速度但增大安装体积与安装时间；JIT 按需编译减少安装开销但首次运行需解释。ART 结合解释+JIT+AOT，按热度与资源权衡，兼顾启动速度与安装成本。

本题考察 ART JIT/AOT 边界。核心是"安装体积/时间 vs 运行性能"。作答时说明两者权衡。

• register-based ABI
• stack frame 变化
• 兼容边界

Go 1.17+ 的 register-based ABI 把参数与返回值放入寄存器，减少栈帧占用与栈访问，但栈帧仍需保留参数溢出空间与调用者参数区。工程边界：通过寄存器传参减少栈操作、提升性能，但涉及逃逸分析、内联与汇编（ABIInternal）的调整，且 ABI 为内部实现，外部调用经 ABI0 兼容。stack frame 布局随之变化，但对外接口稳定。

本题考察 Go register ABI。核心是"寄存器传参减栈 + 内部 ABI 兼容"。作答时说明 stack frame 与兼容边界。

• LLVM-CFI 的控制流完整性
• KASAN 的内存检测
• shadow call stack

Rust 结合 LLVM-CFI 实施控制流完整性校验，防止控制流劫持；KASAN 做内核内存地址检测，发现越界与使用后释放；shadow call stack 用独立影子栈保护返回地址，防栈溢出。其工程价值是提升 Rust 在安全敏感（如内核）场景的纵深防御，弥补部分安全边界。这些是 Rust 内核/系统级应用的加固手段。

本题考察 Rust 安全加固。核心是"CFI/内存检测/影子栈纵深防御"。作答时说明各机制的价值。

• LC_MAIN 的 entryoff/stacksize
• 入口指定
• 相对 LC_UNIXTHREAD

LC_MAIN 用 entryoff 指定入口点相对 __TEXT 段的偏移，stacksize 指定主线程栈大小，是声明式的入口描述。相比 LC_UNIXTHREAD 直接保存初始线程寄存器上下文（含入口地址），LC_MAIN 更简洁、便于 ASLR 与统一处理，是现代 Mach-O 的入口方式。演进使入口指定更清晰。

本题考察 LC_MAIN。核心是"entryoff/stacksize 声明入口 + 简化 ulixthread"。作答时说明演进。

• .interp 段
• link-self-contained
• 动态链接器

.interp 段指定动态链接器路径。rustc 的 -C link-self-contained=no 表示链接时不自带（self-contained）工具链组件，而依赖系统动态链接器，因此生成的二进制通过 .interp 段引用系统的 ld-linux。默认 self-contained 时可能静态或内嵌部分组件。该选项控制 Rust 二进制对系统链接环境的依赖。

本题考察 link-self-contained。核心是"控制是否依赖系统动态链接器"。作答时说明 .interp 与选项的关系。

• 各重定位类型
• 绝对/相对
• GLOB_DAT/JUMP_SLOT

R_X86_64_64 是 64 位绝对地址重定位，R_X86_64_PC32 是 32 位 PC 相对重定位，R_X86_64_GLOB_DAT 用于把 GOT 表项设为符号地址，R_X86_64_JUMP_SLOT 用于 PLT 跳转槽（函数地址）。触发时机：绝对/相对用于数据与代码引用，GLOB_DAT 处理全局数据指针，JUMP_SLOT 处理函数调用（lazy binding 时首次解析）。它们覆盖不同引用场景。

本题考察重定位类型。核心是"各类型对应不同引用与时机"。作答时说明绝对/相对/数据/函数重定位。

• 体积与启动
• ABI 兼容
• 发布策略

静态链接体积大、启动快、无运行时依赖、规避 ABI 兼容问题，适合离线/容器部署；动态链接体积小、可共享、升级便捷，但依赖运行时 ABI 兼容。发布策略：对可移植与安全敏感场景选静态，对体积与更新频繁场景选动态，或混用（关键库静态、系统库动态）。取舍决定发布形态。

本题考察链接取舍与发布。核心是"体积/启动/ABI 权衡决定发布方式"。作答时说明策略选择。

• buffer ring 的免拷贝
• 边界条件
• 适用场景

buffer ring 通过内核直接写入用户预注册缓冲，减少用户态/内核态拷贝，但工程边界存在：需要预先注册与管理缓冲，缓冲生命周期与并发需协调；对非固定大小或特殊对齐的数据，buffer ring 可能无法完全免拷贝。它适合高并发、固定缓冲的接收场景，边界是缓冲管理复杂度与灵活性。

本题考察 buffer ring 边界。核心是"免拷贝收益 + 管理复杂度边界"。作答时说明适用与限制。

• kprobe 的灵活性
• tracepoint 的稳定性
• 兼容性权衡

kprobe 可追踪任意内核函数，灵活但依赖内核内部符号，跨版本易变；tracepoint 是稳定接口，跨版本兼容但覆盖有限。同一需求下，若目标有 tracepoint 则优先选（稳定）；若需追踪无 tracepoint 的内部函数则用 kprobe（灵活但需处理版本差异）。生产选 tracepoint 保稳定，诊断可用 kprobe 补灵活性。

本题考察探针选择。核心是"稳定性 vs 灵活性权衡"。作答时说明选择依据。

• ring buffer 的容量
• 事件丢失
• 延迟关键场景

ring buffer 容量有限，当事件产生速率超过消费速率时，未写入的事件会丢失（overwrite 或 drop）。在 latency-critical tracepoint 场景，若事件爆发超过 buffer 容量，可能丢失关键事件，影响分析完整性。工程边界是平衡 buffer 大小、消费速率与事件频率，必要时用检出丢失（如 dropped counter）识别数据缺失。

本题考察 ring buffer 丢失。核心是"容量限制导致丢失 + 延迟关键场景风险"。作答时说明丢失边界。

• -Z sanitize=cfi
• cargo-cfi
• CFI 加固

Rust nightly 的 -Z sanitize=cfi 启用控制流完整性（CFI）插桩，在间接调用处插入类型校验，防控制流劫持；cargo-cfi 是集成 CFI 的 cargo 工具，封装编译与链接配置。工程应用是在安全敏感（如内核、高安全服务）场景加固 Rust 二进制，防止虚构函数指针/跳转攻击。代价是运行时开销与工具链要求。

本题考察 Rust CFI。核心是"CFI 插桩防控制流劫持 + cargo 集成"。作答时说明应用与代价。

• perf_event_open 的事件关联
• lazy binding count
• PLT 性能评估

plt-bench 用于评估 PLT 与 lazy binding 的开销，通过 perf_event_open 关联性能事件，统计 lazy binding 触发次数与调用开销。其工程价值是量化 PLT 跳转与绑定延迟，帮助决定是否启用 -z now 或优化绑定策略。lazy binding count 反映实际绑定次数，指导性能优化。

本题考察 plt-bench。核心是"量化 PLT/lazy binding 开销"。作答时说明其评估价值。

• .interp 的路径
• 解释器路径选择
• 兼容性

.interp 段以字符串形式保存动态链接器路径，如 /lib64/ld-linux-x86-64.so.2。加载器按此路径加载解释器。x86-64 上的路径由 glibc 与发行版约定，不同发行版可能路径不同，硬编码路径影响跨发行版兼容。为提升兼容性，发行版通过符号链接或 keep 标准路径，使按 .interp 加载的二进制跨发行版运行。

本题考察 .interp 路径。核心是"路径硬编码与跨发行版兼容"。作答时说明路径约定与兼容策略。

• wit-bindgen 的绑定
• 多语言支持
• 组件互操作

wit-bindgen 根据 WIT 接口生成 Rust、C、Go 等语言的绑定代码，让各语言组件通过 Component Model 接口互操作。其工程价值是屏蔽语言差异，让开发者用熟悉语言编写组件，再经标准接口组合，实现跨语言模块化。WASI Preview2 + wit-bindgen 支撑多语言 WASM 组件生态。

本题考察 wit-bindgen。核心是"多语言绑定 + 组件互操作"。作答时说明其跨语言价值。

• 各运行时支持
• WASI 应用
• 跨平台部署

wasmtime、wasmer 等运行时支持 WASI Preview2，让 WASM 应用在服务端运行；wasmCloud 用 WASM 组件构建分布式应用，基于 WASI 与 Component Model 做模块化。工程应用是让一套 WASM 组件跨运行时与平台部署，实现可移植、隔离的服务端执行。WASI 支撑服务端 WASM 生态。

本题考察 WASI 运行时。核心是"跨运行时可移植 + 服务端应用"。作答时说明其应用价值。

• 常量池
• access flags
• 类元数据

.class 的常量池存放字符串、类型、方法名等常量引用，access flags 记录类/成员的访问修饰符，this/super class 指定本类与父类，interfaces 列出实现的接口。javap 读取这些结构反汇编类信息，展示类定义、常量、字节码与签名。这些字段是 javap 解析与展示 .class 的基础。

本题考察 .class 结构。核心是"常量池/访问标志/继承信息支撑 javap"。作答时说明各字段作用。

• 计数结构
• instrumentation
• 解析与改写

.class 的 methods_count、fields_count 记录方法数与字段数，instrumentation 工具（如 ASM、字节码代理）解析时据此定位方法表与字段表，遍历或改写字节码。计数字段是解析 .class 布局的索引依据，工具据此安全遍历并注入代码。其工程价值是支撑字节码插桩与代理的精确遍历。

本题考察计数结构。核心是"计数支撑字节码解析与改写"。作答时说明 instrumentation 用途。

• JVM TI 事件
• method entry/exception
• monitor 拦截

JVM TI 允许 native agent 注册回调，拦截 method entry（方法进入）、exception（异常抛出）、monitor（监视器进入/退出）等事件，从而在不修改字节码的情况下观察 JVM 行为。其工程价值是支撑 APM、性能分析、安全监控等工具，实现低侵入的观测与治理。这些事件是 JVM 可观测性的基础。

本题考察 JVM TI 事件。核心是"拦截方法/异常/锁事件实现观测"。作答时说明其工程价值。

• ThreadLocalStorage
• 替代 JNI env
• 跨线程管理

JVMTI 提供的 Get/SetThreadLocalStorage 接口，让 native agent 为每个线程关联独立数据，替代旧的基于 JNI env 的线程本地存储方式。其工程价值是更规范、可跨 JNI 层管理线程数据，避免依赖 JNI env 生命周期，提升 agent 的健壮性与可移植性。它是 JVM TI 接口演进的重要改进。

本题考察 JVMTI TLS。核心是"ThreadLocalStorage 规范管理线程数据"。作答时说明其演进价值。

• 各 ID 表
• dex 索引结构
• 指令引用

.dex 用多个索引表组织数据：string_ids 存字符串、type_ids 存类型、proto_ids 存方法原型、field_ids 存字段、method_ids 存方法。指令通过这些 ID 引用常量，紧凑高效。该结构支撑 dex 的紧凑编码与快速解析，是 D8/R8 与 ART 处理的基础。ID 表让 dex 以索引而非内联方式引用实体，节省空间。

本题考察 dex 结构。核心是"索引表组织引用 + 紧凑高效"。作答时说明各 ID 表作用。

• PT_NOTE 段
• 寄存器与内存
• 调试重建

Linux core dump 的 PT_NOTE 段保存进程崩溃时的寄存器与内存状态，包括 NT_PRSTATUS（通用寄存器）、NT_FPREGSET（浮点寄存器）、NT_PRPSINFO（进程信息）等 note。调试器（gdb）读取这些 note 重建崩溃现场与调用栈。PT_NOTE 是 core dump 中"现场快照"的关键载体。

本题考察 core dump note。核心是"PT_NOTE 保存寄存器状态供调试重建"。作答时说明其语义。

• core_pattern 的管道化
• systemd-coredump
• 自动收集

/proc/sys/kernel/core_pattern 可配置 core dump 的生成方式，管道化（以 | 开头）时把 core 交给管道程序（如 systemd-coredump）处理，实现自动收集、压缩与存储。工程价值是无需配置即可统一采集 core、按策略管理，并可通过 gdb 分析。systemd-coredump 让 core 管理自动化、可检索。

本题考察 core_pattern 管道化。核心是"管道交给处理器自动收集 core"。作答时说明其工程价值。

• NT_PRSTATUS 的通用寄存器
• NT_FPREGSET 的浮点寄存器
• gdb 重建

NT_PRSTATUS 保存通用寄存器（如 rax、rbx、rsp、rip）与线程状态，NT_FPREGSET 保存浮点/向量寄存器（XMM、FPU 状态），NT_PRSTATUS 还含程序计数器等。gdb 读取这些 note 恢复各线程的寄存器现场，结合栈与程序计数器重建调用栈与崩溃位置。这些 note 是现场重建的数据源。

本题考察 coredump note。核心是"通用/浮点寄存器 note + gdb 重建现场"。作答时说明寄存器保存与重建。

• mmap 内存转储
• 实存内存转储
• 体积取舍

coredump 默认转储实存（物理内存）内容，体积较大；mmap 映射的文件区域（file-backed mmap）内容通常不转储（因为可从文件恢复）。工程取舍：转储实存能还原进程现场但体积大，跳过 mmap 文件区可减小体积，但需从文件恢复。按调试需求与体积权衡选择转储范围。

本题考察 coredump 取舍。核心是"实存 vs mmap 文件的体积权衡"。作答时说明取舍。

• 压缩与保留
• journalctl 检索
• 磁盘控制

systemd-coredump 通过 /etc/systemd/coredump.conf 配置压缩（Compress）、存储位置（Storage）与保留策略（ProcessSizeMax、ExternalSizeMax 等），控制 core 的保存与磁盘占用。core 摘要可写入 journal，用 journalctl 检索。通过限制大小、启用压缩与定期清理，控制磁盘占用。这些配置让 core 管理可持续。

本题考察 systemd-coredump 配置。核心是"压缩/保留/检索配置控制磁盘"。作答时说明配置要点。

• vmlinux BTF
• kernel 5.x
• CO-RE 基础

Linux 5.x 起官方在 vmlinux 中嵌入 BTF 信息（CONFIG_DEBUG_INFO_BTF），发布带 BTF 的内核。其工程价值是让 eBPF 工具（CO-RE）无需额外安装内核头文件即可重定位内核结构，跨内核版本可移植。vmlinux BTF 是生产 eBPF 生态的基础，支撑可移植的可观测性工具。

本题考察 vmlinux BTF。核心是"官方 BTF 支撑 CO-RE 可移植"。作答时说明其价值。

• LC_LOAD_DYLIB 的依赖
• LC_REEXPORT_DYLIB 的再导出
• dyld 解析

LC_LOAD_DYLIB 声明需要加载的依赖库，dyld 据此加载依赖；LC_REEXPORT_DYLIB 声明把某库的符号再导出给当前库的使用者，隐藏中间库。工程价值：前者组织依赖链，后者让库重新导出第三方符号而不直接依赖，简化 API 面。dyld 据这两个命令解析依赖与符号可见性。

本题考察 Mach-O 依赖命令。核心是"加载依赖 vs 再导出符号"。作答时说明 dyld 解析作用。

• .symtab 的剥离
• .dynsym 的保留
• 调试与运行

.symtab 是完整符号表，strip 后通常被移除，影响调试与 nm 但运行不受影响；.dynsym 是动态符号表，运行必需，strip 后仍保留。工程差异：not-stripped 可调试（含 .symtab），stripped 体积小但需调试文件或 build-id 关联。二者区分"调试符号"与"运行符号"。

本题考察 .symtab/.dynsym。核心是"剥离影响调试不影响运行"。作答时说明差异。

• .gnu.hash 的结构
• 查找复杂度
• 启动加速

.gnu.hash 是 GNU 的符号哈希表，采用更优的哈希布隆（Bloom filter）与链式结构，查找效率高，接近 O(1)；sysv hash（.hash）是传统哈希表，最坏 O(N)。工程价值：.gnu.hash 加速动态链接器符号查找，减少启动时间，尤其符号多时。它替代 .hash 提升链接性能。

本题考察 .gnu.hash。核心是"高效哈希查找加速符号解析"。作答时说明其相对 .hash 的优势。

• Bloom filter 机制
• 加速解析
• 工程价值

.gnu.hash 用 Bloom filter 快速判断符号"是否可能在内"，用哈希位与位数组检测，避免对不存在的符号做完整哈希查找，从而加速 dynamic linker 的符号解析。工程价值是减少符号查找的哈希计算与比较，提升动态链接启动性能。Bloom filter 是 .gnu.hash 加速的关键。

本题考察 .gnu.hash Bloom filter。核心是"布隆过滤器快速排除符号加速解析"。作答时说明其加速机制。

• .interp 的路径
• 解释器选择
• 加载流程

.interp 段保存动态链接器路径，如 /lib64/ld-linux-x86-64.so.2，内核加载可执行文件时读取该路径并加载对应解释器。工程价值是让程序指向正确的动态链接器，保证动态库解析与重定位正确。路径由编译链与发行版约定，是动态链接启动的关键。

本题考察 .interp 路径价值。核心是"指定解释器保证动态链接"。作答时说明其作用。

• .fini_array 的槽位
• 调用顺序
• 析构执行

.fini_array 存放进程退出时由运行时调用的析构函数指针（如 C++ 全局对象析构），glibc 退出时按逆序（自数组末尾向前）遍历调用，与 .init_array 的正序构造相反；而 atexit/__cxa_atexit 注册的处理器保存在运行时退出处理器链表（__exit_funcs）中，按注册逆序（LIFO）执行——二者是相互独立的机制。工程上依赖此顺序保证资源释放与析构的正确性。退出时运行时按 .fini_array 遍历调用。

本题考察 .fini_array。核心是"退出时析构函数调用顺序"。作答时说明构造/析构顺序关系。

• .preinit_array 的时机
• .init_array 的时机
• 执行顺序

.preinit_array 的初始化函数在动态链接器完成自身初始化、装载主程序以后、dlopen 加载其他库之前执行，只对主程序有效；.init_array 的初始化函数在程序启动（或库加载）时执行。顺序是 preinit_array 先于 init_array，且 preinit 在 dlopen 之前。工程上利用此顺序做最早的初始化。

本题考察 init 数组顺序。核心是"preinit 在 dlopen 前、先于 init"。作答时说明执行时序。

• .rela.dyn 的处理
• .rela.plt 的处理
• 绑定时机

.rela.dyn 存放数据段与全局符号的重定位（如 GLOB_DAT），在动态链接器加载时不依赖 lazy binding，通常在启动时立即处理；.rela.plt 存放函数调用的重定位（JUMP_SLOT），配合 lazy binding 在函数首次调用时处理（除非 -z now）。两者按绑定策略分时处理，NOW 时 .rela.plt 也启动时处理。

本题考察重定位时机。核心是"数据重定位启动时 vs 函数重定位 lazy"。作答时说明处理时机。