工程在调试配置下运行正常，换成优化版本后，等待循环不再退出，或者计算结果发生变化，这时不能仅凭“关闭优化就恢复”判断编译器出了问题。优化会改变指令安排、变量保存位置和执行时间，也可能暴露原先被掩盖的代码错误。Green Hills MULTI提供了面向调试、通用、体积和速度的优化策略。选择哪一种，需要结合工程目标；结果出现差异时，则要找到具体从哪里开始不同。

工程新增一块缓冲区后，链接提示RAM空间不足，但源文件只多了几行，这时可以从map文件查起。它记录了链接后的段地址、大小及符号等信息，能帮助定位空间分配到了哪里。查看时要把内存区域、段和具体对象分开理解，也要区分链接时预留的空间与程序运行中的实际使用量。

更新公共库后应用链接失败，同一工程换个目录就找不到头文件，这些现象都可能与工程依赖有关。不过，构建顺序、搜索路径和库版本需要分别检查。Green Hills怎么管理工程依赖Green Hills工程依赖关系出错如何排查，可以从MULTI的工程结构与实际构建命令入手。以下以使用.gpj文件的MULTI工程为例，界面名称以所用版本为准。

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

给嵌入式工程增加一个大数组，链接时提示空间不足；调整程序起始地址后，下载成功却进不了主函数。这两类问题看起来不同，都可能与链接布局有关。Green Hills MULTI通过.ld链接指令文件安排代码、变量和栈等内容的存放位置。配置时既要考虑芯片有哪些存储资源，也要顾及启动代码怎样使用这些资源。已有工程中的链接文件可以作为修改起点，改动后的地址则需要通过映射文件和板上运行结果来确认。

Green Hills工程里，目标处理器并不只是一个芯片名称。编译器会根据处理器型号决定可用指令和相应的代码生成方式，调试环境还要用同一套硬件信息去连接目标板。Green Hills目前覆盖ARM、Power Architecture、AURIX/TriCore、RH850、x86、RISC-V等处理器平台，不同工具链安装包能够选择的具体型号并不相同。工程从旧项目复制过来、更换开发板或者升级芯片后，如果仍沿用原来的处理器配置，编译可能报错，也可能直到下载运行时才暴露问题。

嵌入式程序跑通以后，测试做没做到位，光看几次正常运行很难判断。有些异常分支平时根本进不去，有些函数只在特定输入下才会执行，这时就要借助代码覆盖率去看哪些基本块和源码行真正跑过。Green Hills MULTI提供了覆盖率和Profiler相关功能，但采集方式会受到工具链版本、目标环境以及调试连接方式影响。碰到结果里少了几个函数、某些文件没有数据，也不能直接认定测试没跑到，编译选项和数据回传同样值得检查。

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

嵌入式程序进入板级调试以后，问题就不只在代码里了。开发电脑、MULTI、调试探针、目标板和处理器之间只要有一处配置没对应好，程序可能已经编译通过，却停在下载或连接阶段。Green Hills的调试方式还会随目标处理器和连接设备变化，有的工程走JTAG，有的使用SWD或其他接口。碰到连接失败时，把软件配置和硬件链路分开检查，往往比反复重新连接更容易找出原因。

Green Hills MULTI里的工程和普通桌面IDE不太一样，项目结构往往会和目标处理器、运行环境、链接布局一起确定。工程刚建好时，即使源码只有几个文件，只要目标板、工程层级或者路径配置有一处没对上，构建时就可能连续出现找不到头文件、链接文件缺失、目标架构不匹配等报错。遇到这种情况，与其盯着最后一条错误反复修改，不如从顶层工程和较早出现的构建信息往下查，思路会清楚很多。