在Green Hills的MULTI里，链接阶段由elxr把目标文件与库合成可执行文件，很多报错表面看起来像代码问题，实际根因常落在库没被链接、链接脚本内存布局不一致、或段映射规则写错。把报错先分型，再用map文件回看段与符号的落点，通常能把定位范围从全局缩到一两处配置文件或某个库条目。

　　一、Green Hills编译器链接报错

　　链接报错先别急着改源码，先看报错关键词与编号，把它归到符号解析、段布局、启动与运行库这三类里，后续每一类都有明确的检查入口。你越早把问题归类，越容易避免在不同设置里来回试错。

　　1、报错出现unresolved symbols或unresolved symbol

　　这类通常是某个符号只声明或被引用，但定义所在的目标文件或静态库没有被加入链接，先检查该库文件扩展名为.a是否已被加入到程序的链接输入列表，再检查库搜索路径是否指向了实际位置。

　　2、报错指向C++运行时符号例如operator new或operator delete

　　这种常见于用C方式触发链接或漏掉C++标准库，表面是某个符号缺失，本质是C++运行库没有参与链接或链接方式不匹配，优先回到构建选项里确认当前程序使用的语言与对应库集合一致。

　　3、报错出现section overlaps或overlap

　　这类属于链接脚本里的段布局冲突，典型现象是某个只读数据段增长后压到data段位置，先用map文件确认冲突段的起始地址与长度，再回到链接脚本扩大对应区域或调整段的放置顺序与目标内存区。

　　4、报错出现small data overflow或与sdata sbss rosdata相关

　　这类多与小数据区定义不完整有关，常见问题是SDA边界符号或基址定义方式不正确，导致小数据段溢出或被放到不期望的区域，先检查链接脚本里对小数据区相关符号与段顺序的约束，再结合map文件看这些段的实际大小是否超出预期。

　　5、报错看起来像脚本或工具链问题但你找不到入口文件

　　先确认你用的是哪一个程序布局与哪一个链接文件，很多时候同一套工作区里存在多个基础ld文件与自定义ld文件，实际链接用到的那个并不是你正在编辑的那份。

　　二、Green Hills链接脚本怎么检查

　　链接脚本检查的目标不是逐行读完，而是快速确认三件事：内存区定义是否符合芯片手册，段映射是否把关键段放到了正确的内存区，最终输出是否与map文件一致。只要把这三件事核对清楚，大多数链接报错都能落到可改动的位置。

　　1、先确认当前程序实际选用的ld文件

　　在MULTI Project Manager里选中Program节点后右键，进入【Configure】或对应设置入口，在Program Layout里选择当前使用的链接选项与对应的ld文件，若需要自定义则在Program Layout里选择Custom并指定你的ld文件，确保你编辑的就是正在生效的那份。

　　2、检查内存区定义是否完整且容量口径一致

　　打开链接脚本后先看MEMORY块，逐项核对每个区域的起始地址与长度，尤其是Flash与RAM分区是否与芯片实际地址空间一致，任何一个ORIGIN或LENGTH偏差都可能引发段溢出或重叠。

　　3、核对SECTIONS映射是否把段放进了正确的内存区

　　重点看.text.rodata.data.bss以及你们自定义段的映射规则，链接文件通常通过SECTIONS指令描述输出段与目标内存区的对应关系，确认只读段进Flash，可读写段进RAM，且对齐约束与段顺序不会把后续段挤出边界。

　　4、涉及从Flash拷贝到RAM运行时核对ROM拷贝规则

　　如果你们有从ROM拷贝到RAM执行的设计，除了源文件里的段声明，还要在链接脚本里同时定义段映射与copy ROM相关指令，并确认启动代码确实执行拷贝，否则会出现链接通过但运行异常或初始化数据不对的情况。

　　5、用map文件做最终核验而不是只看脚本

　　构建完成后会生成程序名后缀为.map的链接映射文件，你可以用它确认段的基址与大小是否符合预期，也可以快速看到每个段由哪些目标文件贡献，必要时在命令行增加-map生成链接映射以便复核。

　　三、Green Hills链接报错定位顺序

　　当你已经知道报错属于哪一类，下一步就是用固定顺序把变量收敛掉，避免一会儿改库一会儿改脚本导致问题形态变化。下面这套顺序的核心是先锁定生效配置，再用map把地址与符号落点讲清楚，最后才动脚本或库列表。

　　1、先在构建输出里锁定实际参与链接的输入

　　确认elxr参与链接时带了哪些目标文件与库文件，尤其是是否存在同名库被不同路径重复加入，或某个关键库根本未进入链接输入，先把输入集锁定再做后续判断。

　　2、打开map文件先看Image Summary与段边界

　　优先检查Image Summary里每个段的Base与Size，看到段大小逼近某个内存区上限时就去对照MEMORY块容量，若出现重叠，直接记录冲突段的起止范围回到SECTIONS定位对应放置规则。

　　3、遇到unresolved symbols按库是否被加入与顺序两步走

　　第一步确认定义所在的.a是否真的加入到链接输入，第二步再处理链接顺序与库搜索路径，很多问题并不是代码缺实现，而是库没有被链接进来或选错了库版本。

　　4、遇到overlap或overflow先改布局口径再谈优化

　　先处理内存区大小与段放置位置，把冲突消掉让链接恢复一致性，再决定是扩大分区、迁移段到另一个区域、还是把大对象拆分到专用段，避免在冲突状态下做性能或体积优化。

　　5、做完改动后用Clean Build验证并保留一份可对比的map

　　每次只改一个点并重新构建，保留修改前后的map文件对比段大小与符号归属变化，这样你能清楚看到是哪一次改动真正消除了报错，也方便后续把规则沉淀到团队的链接脚本基线里。

　　总结

　　Green Hills链接报错的定位关键在于先分型，再把生效的ld文件与链接输入锁定，最后用map文件核对段与符号的真实落点。你按Program Layout确认正在使用的链接脚本，核对MEMORY与SECTIONS映射，再结合map文件去看段是否溢出重叠、库是否缺失，基本能把常见的unresolved symbols、section overlap、small data overflow这几类问题快速收敛到可修改的配置点上。