符号(方法和函数)的基地址(程序计数器)不匹配.关闭 1 [英] Base addresses (Program Counters) of symbols (methods and functions) do not match. Off by 1

查看:34
本文介绍了符号(方法和函数)的基地址(程序计数器)不匹配.关闭 1的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的应用中有一些代码向我发送未捕获异常的堆栈跟踪.

I have some code in my app that sends me the stack trace of uncaught exceptions.

"0   CoreFoundation   0x3ad073ff <redacted> + 186",
"1   libobjc.A.dylib  0x39412963 objc_exception_throw + 30",
"2   CoreFoundation   0x3ad0729d <redacted> + 0",
"3   Foundation       0x39f3b7b3 <redacted> + 90",
"4   UIKit            0x34a3ae29 <redacted> + 4184",
"5   MyApp            0x0001feab -[MAMyClassA firstMethod:withParameter1:andParameter2:] + 374",
"6   MyApp            0x000f76b5 -[MAMyClassB secondMethod:withParameter1:andParameter2:] + 164",
"7   UIKit            0x34bd0fe1 <redacted> + 84",
"8   UIKit            0x34af2047 <redacted> + 70",
"9   UIKit            0x34af1ffb <redacted> + 30",
"10  UIKit            0x34af1fd5 <redacted> + 44",
...

如您所见,Apple 的大部分方法都替换为 <redacted>.我已经能够使用 nm 从 Apple 库中提取符号及其对应的基地址,但地址不匹配.他们落后 1 点.

As you can see, most of Apple's methods are replaced with <redacted>. I have been able to extract the symbols and their corresponding base addresses from Apple's libraries using nm, but the addresses do not match. They are off by 1.

我已经按照此处的说明计算了地址:iOS 崩溃报告:atos 没有按预期工作.

I have calculated the address as explained here: iOS crash reports: atos not working as expected.

Symbol address = (base address of framework) - (base address of symbol from crash report) + (virtual memory slide [vmaddr]).

例如,我得到的是 0xC2345,但 nm 返回的实际符号地址是 0xC2344.我知道这是正确的符号.我已经在不同的崩溃报告中使用不同框架(UIKit、Foundation、CoreFoundation 等)中的不同地址进行了尝试,结果是相同的:该值始终为 1.我必须从我得到的值中减去 1崩溃报告以获取 nm 提供的正确"地址.

For example, I'm getting 0xC2345, but the actual symbol address returned by nm is 0xC2344. I know that this is the right symbol. I have tried this with different addresses in different frameworks (UIKit, Foundation, CoreFoundation, etc.) in different crash reports and the result is the same: the value is always off by 1. I have to subtract 1 from what I get in the crash report to get the "right" address as provided by nm.

当我输入这个问题时,我发现:Wrong methodotool for armv7的实现地址?.

As I am typing this question, I found this: Wrong method implementation address from otool for armv7?.

这是否意味着每次我要查找地址时都必须执行以下逻辑?

Does that mean that every time I have an address to look up I have to perform the following logic?

if ((symbol address) mod 2 == 1) {
  // This is a thumb instruction so it may be 2 or four bytes
  Subtract 1 from the symbol address and then use it to lookup the symbol.
}
else {
  // This is a standard 4-byte ARM instruction.
  Perform symbol lookup with the address as is.
}

提前感谢您的任何帮助或指导.

Thanks in advance for any help or direction.

推荐答案

PC中的LSB显示当前的执行模式.如果该位为 0,则为 ARM,如果设置为 1,则在 Thumb 模式下执行.所以是的,你会得到这样的真实地址:

The LSB in the PC shows the current execution-mode. If the bit is 0 then it's ARM, if it's set to 1 then the execution is done in Thumb-Mode. So yes, you'll get the real address like this:

real_address = address & ~1;

而当前的执行模式是这样的:

And the current execution mode like this:

is_thumb_mode = address & 1;

如今的大多数代码都将被编译为 Thumb-2,因为它只有少数区域缺少真正的"ARM 代码,并且通常可以节省大约 30% 的代码大小.

Most code these days will be compiled to Thumb-2 as it has only a few areas where it lacks behind "real" ARM-code and usually saves about 30% in code size.

这篇关于符号(方法和函数)的基地址(程序计数器)不匹配.关闭 1的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆