在Green Hills工程里，调试信息能不能出来，关键不在调试器窗口，而在编译和汇编阶段有没有把符号一起带进目标文件。现成可核对的工具链资料显示，GHS编译阶段的调试信息主要由【-G】控制，DWARF2信息由【-dwarf2】控制，面向调试的优化策略则对应【-Odebug】；汇编阶段也有单独的【-G】开关。也就是说，符号丢失很多时候不是“调试器坏了”，而是某一段构建链没有把调试信息完整生成出来。

　　一、Green Hills怎么生成调试信息

　　先把生成链条收顺，后面调试器里能不能看到源文件、函数名和局部变量，基本就取决于这几项。对现有GHS编译配置资料来说，最核心的就是编译调试级别、DWARF2输出和适合调试的优化策略。

　　1、先在编译选项里打开【-G】

　　现成的GHS CCRH850构建工具说明明确写到，【Debugging Level】对应的是编译驱动选项【-G】；如果不指定，就等于不带这项调试信息开关。做普通源码级调试时，这一项是最先要确认的。

　　2、再把【-dwarf2】一起带上

　　同一份配置说明还写明，【Generate MULTI and Native Information】对应的是【-dwarf2】，默认就是开启状态。它的意义不只是给MULTI自己看，也是在目标文件里保留DWARF2调试信息。要是项目里只开了【-G】没带【-dwarf2】，后面和其他调试链或符号解析工具配合时就更容易出偏。

　　3、优化先用【-Odebug】而不是一上来追性能

　　构建工具文档列出的默认优化策略就是【Optimize for Debuggability】，也就是【-Odebug】。这一步很重要，因为源码级调试最怕指令重排、变量优化消失和行号映射发散。真要先把调试链打通，通常优先用【-Odebug】或必要时更低优化，再去谈性能版配置。

　　4、如果工程里有汇编文件，汇编阶段也要开【-G】

　　很多人只看C或C++编译选项，却漏掉了汇编文件。现成GHS汇编选项说明同样把【Debugging Level】定义成【-G】。这意味着只要项目里混了汇编源码，而这部分没开调试信息，调试器里就可能只丢某一段符号，而不是整工程都没符号。

　　二、Green Hills调试符号丢失怎么检查

　　符号丢失不要一上来就怀疑探针或板卡。更常见的情况，还是编译、汇编、链接三层里有一层没对齐。更稳的排查顺序通常是先查编译选项，再查汇编选项，最后查链接产物和映射文件。

　　1、先查是不是有源文件没带【-G】

　　如果症状是只有部分源文件看不到源码行号、局部变量或函数名，第一步先回编译选项页看【-G】是不是全工程统一打开。因为官方配置说明已经把【Not specify】和【MULTI(-G)】分成两个明确状态，所以这一步最好不要靠印象判断。

　　2、再查汇编文件有没有单独漏开【-G】

　　如果丢符号的正好是启动代码、底层中断入口或手写汇编段，那就优先去看汇编选项页。官方说明很明确，汇编也有自己的【-G】调试级别开关，不会自动继承你对C编译器的所有理解。

　　3、再看当前优化是不是过高

　　如果你在调试器里还能看到函数名，但局部变量不稳定、单步跳行怪异，或者源码和执行位置对不上，排查时要优先回头看优化策略。因为GHS配置项里已经把【-Odebug】和更高优化等级分开列出，实务上这通常意味着调试版和发布版不该混用同一套优化参数。

　　4、最后把【-map】打开，先核对链接产物

　　现成链接选项说明写得很清楚，【Map File Generation】对应【-map】，而且map文件会输出到指定输出目录，文件名使用链接输出文件名再改成【.map】扩展名。官方没有直接把它定义成“查符号丢失专用工具”，但在实际排查里，它很适合拿来核对哪些目标文件真正进了链接结果，这一步尤其适合怀疑某个模块根本没被链接进去的情况。这里后半句属于基于官方map文件输出机制做出的实际排查用法。

　　三、Green Hills调试配置该先看什么

　　真到项目里，最省时间的办法不是等符号丢了再反查，而是先把调试版构建配置单独收出来。Green Hills的编译和调试本来就是一整套工具链，MULTI本身也强调源码级调试能力，所以更稳的做法通常是把“能调试的构建”和“能发布的构建”明确分开。

　　1、先固定一套调试版参数

　　最基础的一套通常就是编译开【-G】、开【-dwarf2】、优化先放在【-Odebug】。先把这套链条打通，再去复制出性能版或发布版配置，会比一套配置来回切安全得多。

　　2、再把汇编和链接也纳入同一套检查表

　　调试信息不是只在编译器这一步决定的。汇编文件的【-G】和链接输出的【-map】都该纳入同一张检查表里，不要只看C文件编译成功就默认整套符号都在。

　　3、版本切换时先确认工具支持关系

　　现成工具支持列表能看到，CS+对GHS RH850编译器的支持是按具体版本逐步增加的。这个信息虽然来自配套IDE文档，不是Green Hills自己的编译手册，但它至少提醒了一件事，编译器版本一变，构建插件和调试链的兼容性也该跟着核对。

　　4、调试异常先查构建，不要先查硬件

　　只要问题表现为函数名缺失、源码断点飘、局部变量看不到，优先级通常都应该先给构建选项，而不是先怀疑探针。因为这类现象和【-G】、【-dwarf2】、【-Odebug】、【-map】这几项的关联，比和探针本身的关联更直接。前半句是结合前面几项官方配置说明得出的实操判断。

　　总结

　　Green Hills怎么生成调试信息，关键是把编译阶段的【-G】、【-dwarf2】和适合调试的【-Odebug】收顺，同时别漏掉汇编阶段的【-G】。Green Hills调试符号丢失怎么检查，最稳的顺序则是先查编译选项，再查汇编选项，最后开【-map】去核对链接结果。把这几层分开看，调试符号问题通常会比一上来盯调试器窗口更容易定位。