接手一个旧工程，编译能通过，warning却不断往外滚，着实让人难以下手。往前翻几屏，又发现不少编号和文件位置完全相同。Green Hills的构建日志里，重复提示、代码问题和配置差异可能混在一起。先弄清每条提示来自哪里，再处理代码和选项，会比从上到下逐行修改更有头绪。

Green Hills工程能够顺利编译以后，链接文件就开始决定代码和数据到底放到芯片的什么位置。这个环节如果只看“链接成功”，很容易漏掉问题，地址范围写错、段被放进不合适的存储区，程序仍可能生成可执行文件，上板后却停在启动阶段。Green Hills的elxr链接器使用.ld链接指令文件描述内存区域和程序段布局，处理这类问题时，工程里的Program Layout、实际生效的.ld文件和map结果要放在一起看。

Green Hills MULTI通过调试探针与目标处理器建立连接后，才能进行程序下载、断点、寄存器查看和运行控制。连接参数看起来已经填写完整，但目标板电压、调试接口、处理器型号、复位状态或JTAG时钟任意一项不匹配，都可能让连接停在通信阶段。处理“Green Hills怎么配置目标板连接，Green Hills连接目标板时一直提示通信失败如何排查”，应先确认探针与电脑之间通信正常，再逐层检查探针到目标处理器的硬件链路。Green Hills Probe与MULTI IDE本身就是用于目标板Bring-up、运行控制和硬件调试的配套方案。

在Green Hills MULTI项目中，预处理宏常用于区分硬件版本、功能开关和不同构建配置。处理“Green Hills怎么设置预处理宏，Green Hills预处理宏修改后没有生效是什么原因”时，重点要确认宏设置在哪个项目、目标或源文件层级，并在修改后让对应文件重新进入预处理和编译。MULTI本身提供项目管理和Builder，可以针对工程调整构建配置。

关于Green Hills启动代码该怎么去配置，还有Green Hills启动代码和芯片入口不匹配的情况要怎么办，遇到这个问题的时候，排查的重点不能只放在启动汇编文件上，芯片的复位机制、链接布局、启动头、向量表和调试脚本，这些东西也要同时去核对。启动代码通常会做的事情，是把栈环境给建立起来，对数据段进行初始化，把BSS段给清零，然后再进到main函数里面去，只要入口地址跟芯片实际上会去取指令的位置没有对准，那么工程就算是编译成功了，程序也可能在复位之后一下子就跑进异常的地址里去了。

嵌入式程序在运行时偶尔跑飞、任务切换出现异常，或者中断的时序表现得不稳定，这种时候光靠设置断点来一点一点地追，往往很难把问题复现出来，所以就需要搞清楚Green Hills的Trace功能是怎么把运行信息给采集上来的，以及万一Trace记录不完整，又该从哪些方面去排查，这通常要结合MULTI调试器、TimeMachine回溯工具还有硬件Trace探针这几样东西一起来看才行。Green Hills的TimeMachine可以自动把程序实际执行的数据给捕获下来，然后让调试器能够往前或往后去分析程序跑起来的过程，而Green Hills Probe V4这类的探针也提供了高速的Trace存储空间和足够的带宽，专门用来采集程序运行当中的跟踪数据。

要把这种问题排清楚，关键是把Green Hills调试器的连接链路拆开看：电脑端先把探针识别稳定住，接口端把JTAG或SWD的口径对齐，板端再确保复位与启动阶段不会把调试口关掉。你按这个顺序走，每一步都能得到明确结论，排查会快很多。

Green Hills MULTI怎么配置编译，Green Hills MULTI编译选项怎么管理，很多人第一次在Green Hills MULTI里编译工程，表面问题是“点了Build却报错”，实际往往是三件事没对齐：目标架构与BSP没选准、编译链路的输入输出没固定、编译选项在多人协作里被改成了碎片。

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

在Green Hills里，map文件不是附带产物，而是看链接结果和内存占用最直接的一份清单。公开资料里已经写得很明确，链接阶段可以通过`-map`生成map文件，也可以用`-Map=<map_file_name>`指定输出文件名；另外，`-Mn`还能把符号按地址排序输出。也就是说，想看map文件，前提不是先去IDE里找某个神秘窗口，而是先确认链接时已经把map产出来了。