在调试Bootloader、应用程序、操作系统的镜像，或者那种分成好几段的固件时，常常会碰到符号文件该怎么加载进去，以及符号里头的地址跟板上实际运行的地址对不上该怎么去修正的问题。在TRACE32这个调试工具里面，当你加载一个ELF或者AXF文件的时候，一般既可以把这个文件里面的代码和数据真正地下载到目标板上去，也可以只把其中的调试符号给加载进去。如果目标板上跑的程序是之前就已经烧进Flash里的，或者是在启动的时候被Bootloader搬到了RAM里面，那就一定要把“把程序下载进去”和“只加载符号”这两种情况分得清清楚楚。按照Lauterbach的教程里说的，Data.LOAD这个命令既可以用来把代码和调试符号一起加载，也可以靠着给它加上一个【/NoCODE】的参数，来实现只加载调试符号的效果。

　　一、TRACE32符号文件怎么加载

　　在你准备加载符号文件以前，得先保证调试器跟目标板之间的连接是正常的，而且要确定手头这份符号文件，跟板子上正在跑的那段程序，是来自同一次编译的结果。别看那个ELF文件表面上只是一个调试用的文件，可它的内部其实是包含着代码段要放在哪个地址、调试的信息、程序的入口点，还有源代码存放的路径这些内容的，一旦版本没能对上，后面下断点的时候位置就很容易出错。

　　1、连同代码和符号一起加载

　　要是你需要把程序直接下载到目标板的内存里面去跑，那就可以在命令行里敲上【Data.LOAD.Elf app.elf】这样一条命令。这条命令会根据ELF文件里面记录的那些描述，把代码段和数据段都给搬到内存里去，同时也会把调试需要用到的那些信息加载进TRACE32里面。Lauterbach的支持回复里面也说明了，Data.LOAD.Elf这条命令默认是会去加载代码或者数据的，除非你特意去用了【/NoCODE】这个选项，同时它也会去加载调试信息，除非你又额外用了【/NosYmbol】这个选项。

　　2、只加载符号而不动代码

　　假如板子上的程序现在已经在Flash里面运行起来了，又或者是Bootloader已经把应用程序给搬到了RAM当中，这个时候就不要再往目标内存里面覆盖东西了。碰到这种情况，你就可以用【Data.LOAD.Elf app.elf/NoCODE】这条命令，让工具只把符号信息给加载进去。在官方教程里，面对那种Bootloader已经把应用程序搬到RAM里面去执行的场景，也给出了完全一样的这种用法。

　　3、看一看符号到底有没有生效

　　等加载的动作完成了之后，你可以利用【sYmbol.Browse】这个窗口，或者直接去源码显示的那个界面里，瞧一瞧函数的名字、全局变量，还有源文件的路径是不是都能正常显示出来。然后再试着给main函数、Reset_Handler，或者其他某个你已经知道的函数打上一个断点，看看它能不能停到一个看起来合理的地址上，要是断点能够正确地命中，那就表明这些符号基本上已经生效了。

　　二、TRACE32符号地址对不上怎么修正

　　当你发现符号里面记录的地址和实际运行时的地址对不上时，常见的一些表现就是源码的某一行跟程序计数器PC的值不一致，断点怎么也打不住，变量在那个观察窗口里面显示得稀奇古怪的，或者是函数的名称落到了一个明显是错误的地址上。在动手处理这些现象的时候，不要一上来就着急去修改源代码，而是应该先判断一下问题到底是出在文件的版本上、加载的地址上，还是代码实际运行的那个地址上。

　　1、先确认一下ELF文件的版本

　　你需要把当前板子上跑的那份固件，跟编译出来的产物、map文件、git的提交号，还有当初烧录的时间放到一块儿做一个对比。要知道，符号文件只要不是同一次构建出来的，里面记录的地址就有可能会偏掉，尤其是在你打开了编译优化、调整了链接的顺序，或者是对函数进行了增删之后，哪怕函数的名字还是一样的，它的地址也会发生改变。

　　2、确认你是在只加载符号还是在重新下载

　　如果板子上的代码已经稳稳地待在那里了，可你却不小心又执行了一遍【Data.LOAD.Elf app.elf】这条命令，那就很可能会把目标板的内存给重新覆写一遍。反过来说，如果目标板内存里面躺着的是旧版本的代码，而你却只加载了新版本的符号进去，同样也会造成地址对不上号的情况。所以在现场调试的时候，一定要先搞清楚，现在到底是要把程序下载进去再做调试，还是说只是连接上去以后加载一下符号就可以了。

　　3、检查一下ELF文件里面的地址信息来源

　　在一个ELF文件当中，可能同时会存在着程序头表和节区头表，这些表里面记录着虚拟地址、物理地址、段的大小和节的大小等等这些信息。按照Lauterbach知识库里面的说明，Data.LOAD.ELF这条命令是可以通过一些选项来控制它到底要使用哪些地址和大小信息来加载代码的，比如【/CODEPROG】、【/CODESEC】、【/LOGLOAD】和【/PHYSLOAD】这些参数。要是你发现是链接脚本或者ELF文件头里的信息不太正常，那就需要结合着map文件去判断，此刻到底应该采用哪一种加载的方式。

　　三、TRACE32符号偏移问题怎么定位

　　当符号不是完全错误，而是整体往上或者往下偏差了一个固定的数值时，这种情况多半是和链接之后的重定位、启动时的代码搬运，或者是Flash到RAM的地址映射有关。到了这个时候，就需要拿着map文件去跟实际PC的值做一番对比，千万不要光凭着自己的感觉就去改动脚本。

　　1、拿PC的值和map文件里的地址做个对比

　　你可以让程序在某个确定的函数上停下来，停好之后去瞧一眼PC寄存器里面的值，然后再跟map文件里面记录的这个函数的地址放在一起进行比较。要是发现所有的函数偏差的数值都是一样的，那就说明是一个整体的基地址出了问题；可要是发现不同的函数差值彼此都不一样，那就有可能是代码段、数据段或者整个镜像的版本没有对上。

　　2、处理好有Bootloader参与搬运的那种场景

　　有一些应用程序，它在链接的时候是把运行地址定在了RAM里面，可是存放的地址却在Flash当中，等到板子上电启动以后，是由Bootloader负责把这些代码从Flash搬到RAM里面再去执行的。在这种情况底下，符号所对应的地址就应当跟着实际的运行地址来，而不能去对应它在Flash里面的那个存放地址。Lauterbach的教程里面，就把这类情况归结为应用程序是跑在RAM里面的，并且可以由Bootloader去加载它，对于这种情形，往往只需要再去额外加载一次调试符号就可以了。

　　3、把正确的加载命令给写进脚本里面去

　　等到你把地址的问题给修正好了以后，别忘了把类似【Data.LOAD.Elf app.elf/NoCODE】这样的命令、跟地址相关的那些选项、源码路径要怎么设置，还有断点的命令，统统写到一个.cmm脚本里面去。以后不要再每次都靠人工去点菜单来选择文件了，因为你手工操作的话很难保证每次都是一致的，每次换了一个人来调试的时候，也很容易再犯下加载错文件或者把目标内存给覆盖掉的错误。

　　总结

　　有关在TRACE32里面怎么去加载符号文件，以及在碰到符号地址对不上的时候应该怎么样去修正，先把“连代码带符号一起加载”和“只加载符号而不动代码”这两种情况给区分清楚是很要紧的一步。当需要把程序下载进去的时候，你就可以用【Data.LOAD.Elf app.elf】这条命令，要是目标板上面本来就已经有程序跑起来了，那就该用【Data.LOAD.Elf app.elf/NoCODE】。如果发现地址对不上了，就先要去核对ELF文件的版本、map文件、PC地址、Bootloader搬运过程中的各种关系，还有ELF文件头里面记录的信息，然后再来决定是不是需要去调整加载的方式或者那些跟地址相关的选项。等到把验证好的命令写进了.cmm脚本里面以后，后面的调试工作就会变得稳定很多了。