在Green Hills里做编译和调试时，很多人会把“优化”和“调试”当成同一层设置去处理，结果前面为了跑得快把优化拉高，后面一进调试器就发现变量看不到、单步不顺、代码行和执行路径也开始对不上。Green Hills官方资料对这件事分得比较清楚，编译器本身支持用户可选的performance level和debugging level，而MULTI的Builder又允许你切换不同build configurations，这就说明优化级别和调试可见性本来就该分开管，而不是只改一个编译档位。

　　一、Green Hills怎么切换编译优化级别

　　Green Hills怎么切换编译优化级别，重点不是只找一个叫优化的按钮，而是先确认你当前改的是哪套构建配置。官方对MULTI IDE的说明里明确提到，Builder支持轻松切换build configurations，而编译器又提供performance level和debugging level这两类可选特性，所以更稳的做法是先把配置分清，再去改优化。

　　1、先在MULTI里确认当前使用的是哪套构建配置

　　如果项目里同时有Debug和Release，或者你自己已经拆过不同构建配置，第一步先看当前Builder正在使用哪一套。官方说明里，Builder的特点之一就是build configurations can be easily changed，所以切优化前先站对配置，比直接改全局选项更稳。

　　2、再进入编译选项调整performance level

　　Green Hills官方页面说明，编译器支持user-selectable features，其中就包括performance level和debugging level。实际操作时，切编译优化本质上就是在当前目标配置下调整performance level，让代码更偏向速度、体积或更保守的调试友好状态。

　　3、调优化时不要把debugging level一起忽略

　　很多人只改performance level，不看debugging level，后面变量一看不到就以为是调试器问题。官方同一处说明里把performance level和debugging level并列列出，这本身就说明优化和调试信息是两套独立维度，改优化时最好顺手把调试等级一起核对。

　　4、录一套低优化调试配置，留一套高优化发布配置

　　既然MULTI的Builder天生支持切换构建配置，那更实用的做法不是所有阶段共用一套设置，而是保留一套偏调试的低优化配置，再单独留一套偏发布的高优化配置。这样前期查问题时不必一直和高优化抢变量，后期做性能和体积验证时也不用临时把整套工程推翻重配。这个做法是基于官方对build configurations可切换，以及编译器同时支持performance level和debugging level两层控制得出的。

　　二、Green Hills优化后变量看不到怎么处理

　　Green Hills优化后变量看不到怎么处理，真正要先分清的是，这类现象很多时候不是软件坏了，而是高优化把变量折叠、寄存器化、内联或直接消掉了。Green Hills官方虽然没有在公开页面里逐条展开“变量不可见”的具体情形，但它明确强调了debugging level是编译器的独立可选项，同时也指出optimized code debugging本来就更复杂，因此出现变量不可见时，优先要从编译配置回头看。

　　1、先把当前文件或当前工程切回更低的performance level

　　如果你现在的目标是把变量真正看出来，最直接的处理就是先把当前配置的performance level往下调。因为performance level本身就是控制优化力度的入口，优化越激进，变量越可能被合并、删除或只在很短时间内存在。这个判断是基于官方把performance level明确列为可选编译特性得出的。

　　2、同时把debugging level维持在偏调试的一侧

　　变量不可见时，不要只回退优化，还要一起看debugging level。官方把debugging level和performance level并列列为编译器的用户可选项，说明它本身就会影响调试可见性，所以更稳的处理不是只减优化，而是让调试等级也回到更适合观察变量的状态。

　　3、不要只盯变量窗口，要结合执行历史看

　　Green Hills官方对MULTI的调试能力说明里提到，History viewer用来回答程序怎么走到当前状态、时间花在哪里，以及程序有没有异常行为；TimeMachine还能配合调试器前后回看执行过程。放到“变量看不到”这个场景里，更实用的做法不是死盯当前瞬时值，而是借执行历史去看变量在哪一段逻辑里被改写、折叠或绕过。

　　4、必要时用trace工具替代纯停点观察

　　如果问题只在高优化或偶发路径里出现，单靠传统停点调试很容易看不清。Green Hills官方对Probe V4和TimeMachine的说明里强调了trace capture、History viewer和back-in-time debugging的价值，这意味着当变量在高优化下不稳定可见时，trace反而更适合拿来重建问题路径。

　　三、Green Hills录调配置怎么分开

　　Green Hills录调配置怎么分开，这一步不是在重复前两段，而是在解决为什么很多项目明明知道高优化不利于调试，最后还是会把录制发布配置和日常调试配置混到一起。MULTI官方已经给了很明确的基础条件，一方面Builder支持切换不同build configurations，另一方面编译器又同时提供performance level和debugging level，所以真正可执行的做法，就是把录制发布和日常调试做成两套明确配置，而不是靠每次临时改。

　　1、调试配置优先保可见性

　　日常查问题时，重点是变量看得见、单步走得顺、代码路径容易跟踪，所以这套配置应当优先保留更友好的debugging level，并把performance level控制在更保守的位置。这样做更符合“先把问题查清楚”的目标，而不是先把执行性能推满。这个思路来自官方把debugging level作为独立可选项的设计。

　　2、发布配置优先保性能和体积

　　真正用于交付、测性能或压资源时，再把performance level往高处调。Green Hills官方反复强调它的编译器是optimizing compilers，重点就在generate faster and smaller code，所以发布配置更适合承接这一层目标，不必强求它同时承担最舒适的变量可见性。

　　3、问题只在高优化下出现时保留第三套复现配置

　　有些问题在低优化下根本不出现，这时候只留调试配置和发布配置还不够。更稳的做法是额外保留一套“接近发布但略保调试信息”的复现配置，专门用来抓高优化特有问题。这样既不必完全放弃性能场景，也不会像纯发布配置那样把观察条件压得过低。这个做法仍然是建立在MULTI支持多构建配置切换，以及编译器同时分离performance level和debugging level之上的。

　　4、最后用History和TimeMachine做交叉验证

　　配置分开以后，真正排问题时不要只依赖单一手段。官方已经把History viewer和TimeMachine当成MULTI的核心调试能力之一，用来回答程序怎么来到当前状态和问题源头在哪里，所以当你在不同优化配置之间切换时，这两类工具也很适合拿来交叉验证同一问题在不同构建下的表现。

　　总结

　　Green Hills怎么切换编译优化级别，关键是先在MULTI里分清当前构建配置，再针对performance level去调优化力度。Green Hills优化后变量看不到怎么处理，关键则是不要把它只当成调试器故障，而要先回头核对performance level和debugging level，再结合History viewer、TimeMachine或trace去补观察能力。等这两步都做顺以后，再把Green Hills录调配置怎么分开固定下来，后面的调试和发布通常就不会再互相拖累。