3. 目标系统与工程配置

性能分析能否得到可信结论，很大程度上不取决于分析工具本身，而取决于工程配置是否“可分析”。所谓可分析，是指 MULTI 工程在编译、链接、加载到目标板之后，仍然保留了足够的信息，使 Profiler、Code Coverage、Trace 等工具能够把采样地址、执行计数或事件时间戳准确映射回函数、源文件甚至源代码行。如果目标架构选错、调试连接不稳定、优化级别过高或符号信息被剥离，即使工具界面正常显示数据，结论也可能是失真的。本节围绕“创建可分析的 MULTI 工程”这一目标，梳理目标架构选择、调试连接配置、编译选项与符号信息对性能数据的影响，并给出可复现的配置思路。

一、从工程创建开始：目标架构决定数据解释方式

在 MULTI 中新建工程时，第一步是选择目标架构（Target Architecture）。MULTI 支持 ARM、PowerPC、x86、MIPS、RISC-V 等多种架构，每种架构对应不同的编译器后端、指令集、寄存器模型和调试协议。目标架构一旦选定，编译器生成的指令序列、函数调用约定、栈帧布局都会随之确定，而这些正是性能分析工具解释采样数据的基础。

例如，在 ARM Cortex-M 上，函数调用可能使用 Thumb-2 指令集，返回地址存放在 LR 寄存器；而在 PowerPC 上，返回地址可能保存在链接寄存器或栈帧中。Profiler 在回溯调用栈时，必须知道当前架构的栈帧结构和返回地址保存规则，否则调用关系图会出现断裂或错误归属。因此，创建工程时应确保目标架构与实际运行的芯片一致，而不是选择“兼容”或“近似”的架构。若目标板使用 Cortex-M4F，就应选择对应的 ARM Cortex-M4F 配置，并启用浮点 ABI 选项，否则浮点运算相关的性能数据可能被错误归类。

二、调试连接配置：让数据采集通道稳定可靠

调试连接是性能数据从目标板流向主机的通道。MULTI 支持通过 GDB Server、JTAG、SWD、Trace 探针等方式连接目标系统。配置调试连接时，需要关注三个关键参数：连接接口类型、目标复位方式以及采样/追踪通道的带宽。

以常见的 SWD 连接为例，在 MULTI 的 Debug Configuration 中需要指定 GDB Server 可执行文件路径、目标设备描述文件以及接口速度。接口速度过低会导致采样数据丢失，过高则可能引起连接不稳定。对于性能分析，建议先以中等速度（如 1 MHz）建立稳定连接，再根据数据量逐步调整。若使用 ETM/ETB 等硬件追踪功能，还需要在连接配置中启用 Trace 端口，并分配足够的追踪缓冲区。否则，Trace 工具只能看到函数级信息，无法获取指令级时间戳。

三、编译选项：优化级别直接影响性能数据粒度

编译选项是影响性能数据可解释性的核心因素。MULTI 编译器提供 -O0 到 -O3、-Os 等优化级别，以及 -g、-fno-omit-frame-pointer 等调试相关选项。不同组合对性能分析的影响差异显著。

在 -O0 下，编译器几乎不做指令重排和函数内联，每个源语句对应一段独立的指令序列，Profiler 可以较容易地将采样地址映射到具体行号。但 -O0 生成的代码运行速度慢，可能无法反映真实产品的性能特征。在 -O2 或 -O3 下，编译器会进行函数内联、循环展开、指令调度等优化，采样地址可能落在被内联的函数体内，或者多个源语句共享同一段指令。此时，若没有足够的调试信息，Profiler 只能给出函数级甚至模块级的统计，无法精确到行。

一个实用的折中方案是：在性能分析阶段使用 -O2 -g 组合，既保留接近发布的优化行为，又保留调试符号。若需要精确到行的热点分析，可以临时使用 -O1 -g 或 -O0 -g 进行对比测试，但应明确记录优化级别，避免把 -O0 的结论直接套用到发布版本。

# 推荐的性能分析编译选项示例（MULTI 编译器）
-O2 -g -fno-omit-frame-pointer -fno-inline-functions-called-once

其中，-fno-omit-frame-pointer 保留帧指针，有助于 Profiler 进行调用栈回溯；-fno-inline-functions-called-once 抑制对“仅调用一次”函数的强制内联，减少采样地址归属的歧义。这些选项会轻微影响性能，但能显著提升分析结果的可读性。

四、符号信息：从地址到函数名的桥梁

符号信息是性能分析工具将二进制地址映射回函数名、源文件和行号的关键。MULTI 工程中，符号信息主要来自编译时生成的调试信息（DWARF 格式）和链接时生成的符号表。若编译时未加 -g，或者链接后使用 strip 剥离了符号，Profiler 只能显示地址，无法给出函数名和源码位置。

在 MULTI 中，可以通过以下方式确认符号信息是否完整：在工程属性中检查“Debug Information”是否设置为“Generate”；在链接选项中确认未启用“Strip Symbols”；加载程序后，在 MULTI 的 Symbol Browser 中查看函数列表是否包含源文件路径和行号信息。若符号信息缺失，应重新编译并链接，而不是试图在分析阶段“猜测”函数归属。

此外，符号信息的完整性还影响调用栈回溯的准确性。当函数被内联或尾调用优化时，调用栈可能缺少中间帧。此时，即使符号信息完整，Profiler 也可能显示“inlined”或“tail call”标记。理解这些标记的含义，有助于正确判断热点函数的真实调用路径。

五、配置检查清单与常见误区

在启动性能分析之前，建议按以下顺序检查工程配置。这份清单不是形式化的流程，而是针对性能数据可信度的关键控制点。

另一个需要留意的细节是：当工程中包含多个编译单元或静态库时，每个单元都需要独立的调试信息。如果某个库在编译时未加 -g，即使主程序有完整符号，Profiler 在该库范围内的采样仍然只能显示地址。因此，建议在工程级别统一设置调试信息选项，而不是逐个文件手动添加。

六、从配置到分析：建立可复现的基线

完成上述配置后，建议先执行一次“基线采集”：在目标板上运行一个已知行为的测试用例（例如一个包含固定循环和函数调用的测试函数），用 Profiler 采集 10 秒数据，检查函数列表、调用关系和采样计数是否符合预期。如果基线数据能够正确显示函数名、调用层级和大致耗时比例，说明工程配置已经具备可分析性。此后，再切换到真实业务代码进行性能分析，结论的可信度会显著提高。

需要强调的是，性能分析工程配置不是一次性的工作。当目标板更换、编译器版本升级或优化选项调整时，都应重新检查符号信息和调试连接。只有把配置视为分析流程的固定组成部分，MULTI 的性能数据才能真正支撑优化决策，而不是停留在“看起来有数据”的层面。