Trace32变量看不到，先不要急着怀疑窗口没打开。Lauterbach官方资料里有两个前提说得很清楚，一是TRACE32的HLL调试本身支持优化代码，二是它最终能看到多少变量、多少源码行，仍然取决于编译器给出的调试信息，以及源码和目标代码之间还能不能稳定对应上。也就是说，变量看不到时，排查重点通常不在“TRACE32会不会看变量”，而在“当前构建是不是还保留了足够的调试信息和对象代码映射”。

　　一、Trace32变量看不到先查什么

　　先把问题分成两层看，一层是符号有没有成功加载，另一层是变量在当前优化结果里还存不存在。Lauterbach官方说明里提到，调试信息通常随可执行文件一起加载，其中包含对象代码和源码行的对应关系，可以通过【sYmbol.List.LINE】和【List.Mix】查看；如果某些源码行已经没有对应对象代码，TRACE32连行号都不会显示，这类位置上的局部变量自然也更容易看不到。

　　1、先看源码行还有没有对应目标代码

　　在TRACE32里先用【sYmbol.List.LINE】或【List.Mix】看当前函数的源码行是否还能对应到对象代码。官方文档明确写到，优化可能让某些源码行根本不再生成对象代码，这时TRACE32不会给这些行显示行号。若你盯着的变量正好定义在这类被优化掉或被合并的行附近，窗口里看不到它并不奇怪。

　　2、再看变量是不是被优化掉了

　　GCC官方文档说明，【-g】和【-O】可以同时使用，但启用优化后，某些你声明的变量可能根本不存在，控制流也可能暂时跑到你意料之外的位置，某些语句还可能被搬移或直接省掉。换句话说，TRACE32看到的是编译后的真实结果，不是源码想象中的结果；变量看不到，很多时候不是调试器丢了变量，而是编译器已经把它寄存器化、常量折叠或彻底消掉了。

　　3、确认当前装载的是带调试信息的映像

　　GCC官方文档写得很直接，【-g】用于生成调试信息，格式通常是DWARF。若你装进TRACE32的ELF本身就没有带调试信息，或者你实际装载的是被剥离过符号的产物，变量窗口自然会很空。这个检查要放在前面做，不然你后面再调优化等级，也只是拿“无调试信息”的文件反复试。

　　二、Trace32优化等级与调试信息怎么核对

　　真正要核对时，不要只在TRACE32里看现象，还要回到编译命令本身。GCC官方文档一边说明【-g】负责生成调试信息，一边也明确提醒开启优化会影响调试体验；Lauterbach的资料则补充了另一面，也就是源码和对象代码的映射在低优化级别下会更好。因此核对顺序通常是先看是否带【-g】，再看【-O】到底开到了什么程度。

　　1、先查构建命令里有没有【-g】

　　这是最基础的一步。若编译命令里没有【-g】，就先别继续猜TRACE32设置了，先把调试信息补上。GCC文档明确说明【-g】会生成供调试器使用的调试信息，而【-g0】则等同于不生成调试信息。你要核对的不是工程界面上勾没勾“Debug”，而是实际编译命令最后是不是把调试信息真正带进了目标文件和ELF。

　　2、再查优化是不是开得太高

　　如果当前构建是【-O2】、【-O3】或更激进的发布配置，变量不可见、单步错位、局部变量值跳变这类现象都会明显增多。GCC文档明确说明，不开优化时，调试结果通常更符合源码直觉；而Lauterbach文档也说明对象代码与源码的映射在较低优化级别下效果更好。调试阶段如果以变量可见性为主，通常先把优化降下来再看现象会更直接。

　　3、看调试信息格式是不是DWARF路线

　　如果你用GCC一类工具链，官方文档说明【-gdwarf-版本】可以显式指定DWARF版本，而【-g】默认也会产生系统支持的调试信息格式。对TRACE32这类依赖编译器调试信息做HLL调试的场景来说，调试构建最好保持一套稳定的DWARF输出，不要一会儿带完整调试信息，一会儿换成裁剪过的产物，否则前后现象会很难对齐。

　　三、Trace32里怎样更快收窄原因

　　变量看不到时，效率更高的办法不是一口气重装工具，而是做一组对照构建。因为Lauterbach官方已经说明TRACE32支持优化代码调试，所以真正要确认的是“当前这份构建的调试质量够不够”，而不是泛泛地问“TRACE32能不能调优化代码”。

　　1、先做一份低优化调试包对照

　　拿同一份代码，保留【-g】，把优化先降到无优化或很低的调试构建，再和当前发布构建对照看变量窗口。若低优化版本里变量恢复可见，说明问题基本不在TRACE32，而在优化级别和调试信息质量的组合上。Lauterbach关于代码覆盖率的说明也直接指出，源码和对象代码的映射在低优化级别下会更好。

　　2、用【List.Mix】看具体函数，而不是只盯变量窗口

　　变量窗口只告诉你“现在能不能看到”，【List.Mix】更适合告诉你“为什么看不到”。如果你发现某几行源码已经没有对象代码，或者代码顺序和源码顺序明显被重排，那这类函数里的局部变量可见性本来就会变差。这个判断直接来自Lauterbach对源码行与对象代码映射的说明。

　　3、把问题先归到构建侧，不要先归到脚本侧

　　若同一个ELF在别的版本里变量能看到，在当前版本里看不到，优先回查编译选项和调试信息产物。GCC明确说明优化会让变量可能“不存在”，Lauterbach也明确说明它依赖编译器给出的信息来做HLL调试，所以这类问题大多应先从编译链路收口，而不是先去改TRACE32变量窗口布局。

　　总结

　　Trace32变量看不到Trace32优化等级与调试信息怎么核对，核心不是多开几个变量窗口，而是先确认当前ELF里有没有完整调试信息，再确认优化有没有把源码和对象代码的对应关系拉散。排查顺序可以固定成三步，先查【-g】在不在，再查【-O】开到什么程度，最后在TRACE32里用【sYmbol.List.LINE】和【List.Mix】确认源码行还有没有对应对象代码。这样排下来，通常很快就能分清到底是符号没带上，还是变量已经被优化掉了。