即使工程编译顺利地通过了，最后生成的那份Map文件，也常常会跟事先规划好的内存布局对不上号，比如，变量不知怎么就跑到了错误的RAM区，某个代码段占用的空间一下子变大了，或者有一段地址明明已经设成了固定值，结果却发生了漂移，这些问题，光靠读源码是根本判断不出来的。TASKING链接器在工作的过程里，会把各种目标文件和库文件组合到一块儿，再按照LSL文件里的规则去给它们安排地址，而Map文件里面记录下来的，才是链接完成后真实的内存分布状况。

　　一、TASKING Map文件为什么和预期不一致

　　Map文件出现的结果跟我们设想的不一样，通常倒不是链接器在随意地分配地址，更多的时候，是因为段的匹配没做好、地址空间选得不对、对齐的规则没生效，或者初始化采用的方式出了岔子。所以在排查时，可以先到Map文件里找到真实的段名，再回过头来检查LSL文件里对应规则是怎么写的。

　　1、LSL规则没能匹配到目标段

　　变量被重命名、源文件改了名字，或者整个模块被重新拆解组织以后，编译器生成的段名往往也会跟着变化。假如LSL里的select还在用着旧的那个段名，那目标段就不会被收进我们希望的那个group里，而是继续按照默认的规则去放置。所以，应当先在Map文件中把变量或函数搜出来，再根据搜索结果确定它实际属于哪一个section，之后才去校对LSL。

　　2、group的限制条件不够清楚

　　在LSL里面，group可以设成ordered、contiguous、clustered，也可以带上run_addr。但ordered只是保证了段会按照列出来的先后顺序去摆放，并不能担保它们之间完全没有空隙；contiguous虽然要求这些段必须待在一块连续的地址范围里，却同样可能因为对齐的需要留下缝隙。如果我们的目的是要牢牢固定住首地址，那就必须把run_addr写明确，不能指望其他属性自动完成这个任务。

　　3、多核场景下把地址空间选错了

　　像AURIX这类多核工程，DSPR和PSPR这些内存区，经常会同时存在本地映射和线性映射，两种映射表现的地址数字看上去截然不同，实际指向的却很可能是同一块物理区域。TASKING知识库的例子就提到过，TC0往0x70000000写数据跟往0xD0000000写数据，会落到完全一样的物理地址上。所以核间共享的数据和单核自己用的数据，要分别去核对它们所在的space和memory映射，不然很容易混淆。

　　4、初始化数据还留着ROM副本

　　带有初始值的RAM变量，除了在RAM里有自己的位置之外，还会在Flash里面保留一份初始化的副本，等到系统启动时，再根据copy table把那部分数据从Flash复制到RAM。于是在Map文件里，我们就可能看到两个相关的地址，这个时候不能直接断定是重复分配了。通常，那些被方括号包起来的段名，指的就是ROM copy section，而RAM中对应的地址才是在程序运行时真正会被访问到的地方。

　　二、TASKING Map文件段分布该如何核对

　　检查Map文件时，不能只去搜索一两个变量的地址就停下了，相对稳当的办法，是顺着内存总体占用、定位规则、段的地址以及符号地址这四个层次，一层一层往下看。

　　1、先去看Used Resources

　　可以首先找到Used Resources里面那张叫做“Memory usage in bytes”的表格，挨个查看每块内存区域里，Code、Data、Reserved、Free和Total各占了多少空间。如果某一块RAM突然快被塞满了，或者有些代码跑进了一个原本不该使用的区段，这里往往就能最先看出端倪。要是Map文件里根本就没有这张表，那就需要去检查一下链接参数里的map-file-format是不是还保留着memory相关的选项。

　　2、接着去看Locate Rules

　　Locate Rules会把链接器真正用到的那些定位规则全都列出来，这里面包括地址空间、规则的类型、优先级，还有规则到底适用在哪些段上。我们在这一步着重去核实，目标group有没有如设想的那样落在正确的space里面，run_addr填得对不对，有没有更高优先级的规则把原来的设置给覆盖掉了。

　　3、再去核对Sections

　　在Sections或者Link Result那部分内容里，按照section名称去搜索目标段，搞清楚输入段是从哪一个目标文件里来的，输出的段最终被放在了什么地址上，又占用了多大的空间。函数相关的段、未初始化的数据段、已初始化的数据段，还有只读的数据段，这几种需要分开来检查，不能光凭一个符号名字就下结论。

　　4、最后核对Symbols

　　通过搜索关键变量、入口函数、共享缓冲区以及中断向量这些符号的地址，来确认它们跟设计文档里记录的是不是完全一致。遇到多核项目，还要额外留意那些私有段有没有带上对应内核的标识。TASKING工具链既支持让核心关联属性去影响生成的段名，也允许在LSL里用modify input的办法去重新分配代码段和数据段，这些都需要一并检查。

　　三、TASKING Map文件异常还要检查什么

　　Map文件核对完以后，构建的过程和版本的记录也是必须去看一看的，因为很多地址上的偏差，其实是旧文件没有清理干净，或者不小心把Debug和Release两套配置混在一起用而造成的。

　　1、做一次完整的清理构建

　　只要动过了LSL文件、变量的段名或者芯片相关的配置，就应当先执行一遍Clean，再点下Build重新完整编译。如果只是做了增量编译，那些旧的目标文件很可能还保留着原来的段信息，最终生成的Map文件自然就跟源码的意图对不起来了。

　　2、把Debug结果和Release结果分开

　　不同的构建配置，优化等级可能不一样，用的链接脚本和输出目录也可能不同，而Map文件通常是生成在当前构建配置所对应的Debug或Release文件夹里面。所以在打开查看之前，最好先确认一下文件的生成时间和对应的配置名称，免得看错了版本。

　　3、记录下关键内存区的变化

　　每次快要发布前，可以把Map文件保存下来，同时顺带记一下Flash、RAM、栈、堆以及共享区的占用情况。等到后面某一次构建，占用量忽然出现明显波动时，就可以直接把这一版记录跟上一版进行比对，这样很快就能判断出来，究竟是因为新增了功能，还是哪条规则变了，又或者是哪个段被放错了位置。

　　总结

　　TASKING Map文件之所以跟预期不一致，最常见的原因就集中在段名没能对上、group的限制不够清楚、多核的地址空间挑错了，还有对ROM副本的理解不够准确这几个方面。核对TASKING Map文件里的段分布时，比较建议的顺序，是从Used Resources里的总体占用看起，再到Locate Rules、Sections，最后去核对Symbols，同时别忘了回头去确认LSL文件和构建配置。Map文件绝不是编译流程里一个可有可无的附属品，它是用来核实真实内存布局的一份重要依据，值得花时间仔细读懂。