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

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

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

在Green Hills MULTI中，符号信息是源码调试、函数定位、断点设置和变量查看的重要基础。调试器读取可执行文件中的符号及调试信息后，才能把函数名、变量名与实际地址对应起来。遇到“Green Hills怎么查看符号表，Green Hills符号表中找不到目标函数如何检查”时，除了确认函数是否真的参与编译，还要结合链接结果、优化设置、调试信息以及当前加载的程序映像判断。MULTI支持源码级符号调试，并可使用ELF/DWARF等标准调试输出。

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

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

在安全关键系统的设计里，把不同任务分到不同的目录下面，并不等于就实现了真正的分区隔离。分区要做的事情，是把安全等级、实时性要求、内存使用、设备访问和通信关系这几样东西全都隔离开来，让它们互相之间不会产生不必要的影响。在Green Hills INTEGRITY这个实时操作系统中，划分好分区以及检查每个分区的资源限制，是两项很关键的工作，而且应该先想清楚哪些功能必须互不干扰，再给每个分区分配好固定的资源额度。

很多编译异常、链接失败、运行不稳定，看起来像代码问题，最后却追到Green Hills编译器选错了架构分支，或同一工程在不同人机器上用了不同的工具集。把选型与匹配先做扎实，后面再谈优化等级、告警口径、调试体验，都会顺很多。

在Green Hills工程里，用户口头常说的LSL文件，实际对应的一般就是linker file，也就是linker directive file。公开的厂商资料里对GHS的写法很一致，链接阶段通过`-T<linker_file.ld>`指定链接文件，再通过`-map=<map_file>`生成map文件，所以真正要改的核心，不是编译选项本身，而是这份`.ld`链接文件里的内存区和段分配规则。

做单核调试时，问题大多还能靠来回单步慢慢看清，但一到多核场景，节奏就完全变了。一个核停住，另一个核可能还在继续跑，共享内存、核间中断和消息队列都会继续变化，所以Green Hills多核调试真正难的地方，往往不是代码本身，而是前面的连接方式和当前调试焦点没有先理顺。Green Hills官方资料已经说明，MULTI支持多核系统调试和同步运行控制，Green Hills Probe V4也支持单个JTAG扫描链上的多核调试。