Green Hills的编译优化等级到底要怎么调，还有优化以后变量没有办法被观察到，这要怎么处理，这些问题一般是出现在从Debug版本往性能版本那边切过去的阶段。编译优化会去把函数给内联展开，把没有用到的代码给删掉，重新去分配寄存器，对指令的先后顺序也做一些调整，程序的运行结果虽然没有变，但这可不表示它生成出来的机器代码，跟每一行的源代码还能一一对应得上。Green Hills编译器里面，性能的级别和调试的级别都是可以选的，MULTI调试器则可以把源代码、内存、寄存器，还有函数调用栈放到一起，去查看程序的状态。

想要搞明白Green Hills INTEGRITY工程怎么创建，还有Green Hills INTEGRITY任务启动失败怎么排查，这两个问题只要是用MULTI来开发那种实时嵌入式应用，就绕不过去，一个INTEGRITY工程不是简简单单把几个C文件塞进项目里就完事了，它还要管目标板上的BSP、地址空间怎么分、内核怎么配、任务从哪里进去、共享库怎么弄，还有怎么连到目标板，工程能顺顺利利编译过去，也不等于任务就一定起得来，好多启动的问题其实是卡在了镜像没有正确加载进去，入口函数没配对，依赖的那些服务还没跑起来，或者任务申请的内存和系统资源已经超过了配置给它的范围。

使用MULTI调试嵌入式控制器的时候，Green Hills Flash下载脚本该怎么写，下载以后程序不运行又要怎么办，这类问题是常会碰到的。目标连接、芯片复位、存储器初始化、擦除、写入、校验还有运行这些操作，都可以由Flash脚本给固定下来。脚本执行成功了，也只能说明数据或许被写到了指定的区域里，处理器复位之后能不能从这个地址启动，那还不一定。要是程序没有运行起来，链接地址、启动模式、复位向量和硬件初始化的检查，就得接着往下做。

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

Green Hills链接映射文件怎么查看，以及在其内部遇到内存段溢出的问题要如何处理，这件事，先得把那份map文件当成一份最终的，关于内存的账本来对待，它并不是一份普通的记录，而是链接器把各个目标文件、库文件、段落、符号和地址整理在一块儿之后得到的结果，你的程序究竟能不能被放进Flash、RAM、共享内存或者那些专用的段里面，很多情况下，不用先去把板子跑起来，而是先拿眼睛看一看这份链接映射文件，就能把问题给找出来。

Green Hills MULTI工程怎么配置，Green Hills MULTI工程依赖路径失效怎么排查，这在嵌入式工程迁移、更换电脑、更换工具链版本，或接入CI构建的时候经常能碰到。MULTI工程并不只是用来保存源文件的列表，它还会把编译器、目标处理器、include路径、库路径、链接脚本、启动文件以及构建选项全都关联在一起。路径一旦被写成了个人电脑上的绝对目录，或者项目结构调整后没有同步更新，就容易出现头文件找不到、库文件找不到、链接失败，或者工程能打开却无法编译这一类的问题。

在调试启动代码、中断服务程序、任务切换或者底层外设驱动的时候，光盯着C语言层面的变量往往判断不出真正的问题，直接观察寄存器窗口反而能更快抓住线索。Green Hills MULTI调试器支持多种处理器架构和连接方式，在配合硬件探针时，不仅能设置断点、读写内存，也可以实时查看通用寄存器、程序计数器、堆栈指针、状态寄存器和部分外设寄存器。按照官方资料的说明，成功连接目标之后，通过读写寄存器来验证调试链路是否正常，本身就是一个很基础的检查手段。

在嵌入式项目的开发过程中，只要工程里用到的预编译库稍微多起来，路径设置混乱、不同版本互相覆盖、同一个符号被重复定义这类问题就会变得非常常见，单靠把所有能看到的库文件一股脑儿塞进工程里并不能解决问题。更稳当的处理办法，是先花些力气把每一个库的来源、它所对应的芯片平台、当初编译时用了哪些选项，还有链接过程中各个库的先后次序都理清楚，然后再借助map文件和链接日志，准确地找出到底是哪两个目标文件或者哪两个库之间发生了冲突。

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

在嵌入式项目切到Green Hills编译器之后，头一次做完整构建的时候，经常能看到大量的告警跳出来。要弄清楚Green Hills编译器告警太多到底该先处理哪些，不能只按它们冒出来的顺序一条一条去改，而是得先按风险的高低和影响的范围来分层。Green Hills Optimizing Compilers这套编译器本身就是给嵌入式场景用的，常用在那些对可靠性、性能还有代码质量要求比较高的项目里。告警本身虽然不等于错误，但它的出现往往就是在提醒你，代码里头可能藏着类型、初始化、转换或者可移植性方面的风险。