堆栈跟踪停在叶船级社（LR） [英] stack traces stop at the leaf register (lr)

问题描述

我经常看到ARM的堆栈跟踪（读：Android的NDK堆栈跟踪），与一个 LR 指针终止，就像这样：

Often I see ARM stack traces (read: Android NDK stack traces) that terminate with an lr pointer, like so:

      #00  pc 001c6c20  /data/data/com.audia.dev.qt/lib/libQtGui.so
      #01  lr 80a356cc  /data/data/com.audia.dev.rta/lib/librta.so

我知道 LR 为链接寄存器 ARM和其他架构，而且它是一个快速的方法来存储返回地址，但我不明白为什么它似乎总是存储一个无用的地址。在这个例子中， 80a356cc 无法使用映射到任何code addr2line 或 GDB 。

I know that lr stands for link register on ARM and other architectures, and that it's a quick way to store a return address, but I don't understand why it always seems to store a useless address. In this example, 80a356cc cannot be mapped to any code using addr2line or gdb.

有什么办法来获得更多的信息？为什么一定要在跟踪停止的 LR 解决呢？

Is there any way to get more information? Why must the trace stop at the lr address anyway?

推荐答案

在答案终于跌跌撞撞。我刚要更加细心。看看下面的短堆栈跟踪后，自带的信息：

Stumbled on the answer finally. I just had to be more observant. Look at the following short stack trace and the information that comes after it:

         #00  pc 000099d6  /system/lib/libandroid.so
         #01  lr 80b6c17c  /data/data/com.audia.dev.rta/lib/librta.so

code around pc:
a9d899b4 bf00bd0e 2102b507 aa016d43 28004798 
a9d899c4 9801bfa8 bf00bd0e 460eb573 93004615 
a9d899d4 6d842105 462b4632 200047a0 bf00bd7c 
a9d899e4 b100b510 f7fe3808 2800edf4 f04fbf14 
a9d899f4 200030ff bf00bd10 b097b5f0 4614af01 

code around lr:
80b6c15c e51b3078 e5933038 e5932024 e51b302c 
80b6c16c e1a00002 e3a01000 e3a02000 ebfeee5c 
80b6c17c e1a03000 e50b303c e51b303c e1a03fa3 
80b6c18c e6ef3073 e3530000 0a000005 e59f34fc 
80b6c19c e08f3003 e1a00003 e51b103c ebfeebe6 

现在的 LR 地址仍然是没有什么用处给我们 80xxxxxx 地址

Now the lr address is still a 80xxxxxx address that isn't useful to us.

它从电脑打印地址是 000099d6 ，但看看接下来的部分， code围绕PC 。第一列是地址的列表（你可以从它由16每次递增的事实告诉我们。）这些地址都看起来像 PC 地址，除非你砍关的前16位。然后你会发现 a9d899d4 必须对应于 000099d4 ，以及code程序停止是两个字节在从

The address it prints from the pc is 000099d6, but look at the next section, code around pc. The first column is a list of addresses (you can tell from the fact that it increments by 16 each time.) None of those addresses looks like the pc address, unless you chop off the first 16 bits. Then you'll notice that the a9d899d4 must correspond to 000099d4, and the code where the program stopped is two bytes in from that.

Android的堆栈跟踪似乎已经砍掉的第2个字节 PC 地址给我，但不管是什么原因，它不适合在地址做叶寄存器。这给我们带来了解决方案：

Android's stack trace seems to have "chopped off" the first 2 bytes of the pc address for me, but for whatever reason it does not do it for addresses in the leaf register. Which brings us to the solution:

在短，我能为砍下的前16位从 80b6c17c 地址，使其 0000c17c ，到目前为止已经给了我一个有效的code类地址每一个我可以看看了 GDB 或 addr2line 。 （修改我发现它实际上是一般的在第12位或第3十六进制数字，您可以通过观察决定自己这一点。上述像我的堆栈跟踪输出）。我可以证实它是的右键的code类地址为好。这无疑取得调试一个伟大的有点容易！

In short, I was able to chop off the first 16 bits from the 80b6c17c address to make it 0000c17c, and so far that has given me a valid code address every time that I can look up with gdb or addr2line. (edit: I've found it's actually usually the first 12 bits or first 3 hexadecimal digits. You can decide this for yourself by looking at the stack trace output like I described above.) I can confirm that it is the right code address as well. This has definitely made debugging a great bit easier!

这篇关于堆栈跟踪停在叶船级社（LR）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！