假设我们在gdb中遇到了符号0x0000555555555190
我们可以x/20g $rsp来观察当前函数中的return address(有rbp的基地址，也有return address, 可以通过info line大概猜出来是什么格式)。拿到这个return address - 0x0000555555555190之后，假设我们现在没有符号，我们怎么才能猜出他大概的位置，这个时候我们就需要借助addr2line
上面提到的关闭ASR可以通过setarch -R来进行关闭
但是addr2line他不针对运行地址，他只针对偏移量，这个情况下，我们就遇到一个问题 - 怎么把这个0x0000555555555190转成相对位置。这个情况下我们可以通过info proc m或者直接cat /proc/pid/maps来查看base address
当有了这个base address之后，我们把上面的符号地址减去这个base address，就拿到他的相对位置了，即0x0000555555555190 - 0x0x0000555555554000 = 1190
当我们拿到了这个相对offset之后，我们就可以去让addr2line输出了，即
addr2line -e a.out 1190
我们得到的结果如下
咦，奇怪，我们都已经到了这一步了，怎么仍然没有行号。聪明的你也想到了。因为我们此时的a.out仍然是没有debug symbols的，我们需要重新编一个具有debug symbols的elf,比如app，然后我们重新运行
然后我们来看一下真正的源文件，是否是在调用add_numbers()的返回地址
可以看到解析是成功的，帮我们定位到了这个函数的返回地址，也就是这里的第十五行
PS:
你也可以直接编译有symbols的ELF, 只要保证在同样的一台机器上，然后直接运行info line *address即可
可以看到，通过这个方式我们也能打印出对应的行号。但是因为地址随机化的问题，最好是在同一台机器上，否则这里的Base Address会有出入
addr2line通过-f选项可以打印function name
其实还有更快的办法，我们并不一定一定要去找return address, 其实对我们来说最有用的就是rip以及pc,都表示下一个要运行的地址
我们可以直接通过这个地址减去base address,就可以直接通过addr2line去定位crash的问题
同时如果你的程序本身是开了优化，为了精准定位，你在出debug symbols的时候也尽量带上优化，这样可以保证你的行号是正确的
比如我们这里在不开优化的情况下是15号，但是如果跟原程序一样开了优化，就变成了正确的第14行
PS:
当gdb没有运行的时候，如果直接file a.out,此时查看info functions得到的地址都是相对地址
当程序运行起来之后会把这些相对地址加上start address成为最终的符号地址
