atos给出___lldb_unnamed_function [英] atos gives ___lldb_unnamed_function
问题描述
我有一个崩溃转储，它不会正常符号化 - 当我将它拖入Xcode组织器或手动运行symbolicatecrash时系统符号显示，但应用程序指令地址都未触及。
I have a crash dump which will not symbolicate normally - when I drag it into the Xcode organizer or manually run symbolicatecrash the system symbols show up, but the application instruction addresses are all untouched.
我尝试使用atos来解决这个问题，但我得到的结果是：
I tried using atos to work around this problem, but the result I got was:
got symbolicator for myarchive.xcarchive/Products/Applications/MyApp.app/MyApp, base address 4000
___lldb_unnamed_function2115$$MyApp (in MyApp) + 992
___lldb_unnamed_function2096$$MyApp (in MyApp) + 66
___lldb_unnamed_function6053$$MyApp (in MyApp) + 348
___lldb_unnamed_function6064$$MyApp (in MyApp) + 162
___lldb_unnamed_function6002$$MyApp (in MyApp) + 18
___lldb_unnamed_function1029$$MyApp (in MyApp) + 416
___lldb_unnamed_function2280$$MyApp (in MyApp) + 106
___lldb_unnamed_function2272$$MyApp (in MyApp) + 198
___lldb_unnamed_function400$$MyApp (in MyApp) + 96
___lldb_unnamed_function1$$MyApp (in MyApp) + 36
当前地址被映射到 ___ lldb_unnamed_function1 $$ MyApp（在MyApp中）+ 36 应该与main.m中的根调用相对应。显然，我不知道其他人应该是什么，但我猜测如果一个人错了，他们就错了。什么可能导致这个？ ___lldb_unnamed_function通常出现在块中嵌入的函数以外的任何地方吗？
The address currently getting mapped to ___lldb_unnamed_function1$$MyApp (in MyApp) + 36 should correspond to my root invocation in main.m. Obviously, I don't know what the others should be, but I'm guessing that if one is wrong they're all wrong. What could cause this? Does ___lldb_unnamed_function normally appear anywhere other than functions embedded in blocks?
不幸的是，这会产生一个很长的问题，但是因为在计算负载偏移量时可能会出错应用程序二进制文件我将列出我产生上述输出的步骤。
Unfortunately, this will make for a long question, but since it could be an error in calculating the load offset of the app binary I'll list the steps that I followed to yield the above output.
我用 dwarfdump -u myarchive.xcarchive / Products / Applications / MyApp.app / MyApp 验证我使用的是正确的二进制文件：
I used dwarfdump -u myarchive.xcarchive/Products/Applications/MyApp.app/MyApp to verify that I am using the correct binary:
UUID: BA41E9A3-4BB5-3F8A-8D57-0D16447FFEC6 (armv7) myarchive.xcarchive/Products/Applications/MyApp.app/MyApp
UUID: A6E0970C-05FE-3A79-887D-84F3892637FD (armv7s) myarchive.xcarchive/Products/Applications/MyApp.app/MyApp
崩溃转储中的UUID与第一个匹配：
The UUID in the crash dump matches the first one:
Binary Images:
0x97000 - 0x3cefff +MyApp armv7 <ba41e9a34bb53f8a8d570d16447ffec6> /var/mobile/Applications/AF97EC52-7A2F-4772-AA05-74E739BA6882/MyApp.app/MyApp
此行还将负载偏移列为0x97000，架构为armv7。我感兴趣的地址是：
This line also lists the load offset as 0x97000 and the architecture as armv7. The addresses I'm interested in are:
1 MyApp 0x001357dc 0x97000 + 649180
2 MyApp 0x00134446 0x97000 + 644166
3 MyApp 0x00240cec 0x97000 + 1744108
4 MyApp 0x002416ea 0x97000 + 1746666
5 MyApp 0x0023e2de 0x97000 + 1733342
6 MyApp 0x000de724 0x97000 + 292644
7 MyApp 0x00144f1a 0x97000 + 712474
8 MyApp 0x00144336 0x97000 + 709430
27 MyApp 0x000b1024 0x97000 + 106532
28 MyApp 0x0009d464 0x97000 + 25700
所以我运行 xcrun atos -l 0x97000 -arch armv7 -o myarchive.xcarchive / Products / Applications / MyApp.app / MyApp 0x001357dc 0x00134446 0x00240cec 0x002416ea 0x0023e2de 0x000de7 24 0x00144f1a 0x00144336 0x000b1024 0x0009d464 ，它给了我上面的输出。
So I ran xcrun atos -l 0x97000 -arch armv7 -o myarchive.xcarchive/Products/Applications/MyApp.app/MyApp 0x001357dc 0x00134446 0x00240cec 0x002416ea 0x0023e2de 0x000de724 0x00144f1a 0x00144336 0x000b1024 0x0009d464, which gave me the output above.
注意：因为这看起来不正确，我想也许我需要手动减去幻灯片值。我从应用程序包中获取了它，其中包含 xcrun otool -arch armv7 -l myarchive.xcarchive / Products / Applications / MyApp.app / MyApp ：
Note: since this didn't look correct, I thought perhaps I needed to manually subtract the slide value. I obtained it from the app bundle with xcrun otool -arch armv7 -l myarchive.xcarchive/Products/Applications/MyApp.app/MyApp:
Load command 0
cmd LC_SEGMENT
cmdsize 56
segname __PAGEZERO
vmaddr 0x00000000
vmsize 0x00004000
fileoff 0
filesize 0
maxprot 0x00000000
initprot 0x00000000
nsects 0
flags 0x0
Load command 1
cmd LC_SEGMENT
cmdsize 736
segname __TEXT
vmaddr 0x00004000
vmsize 0x00338000
fileoff 0
filesize 3375104
maxprot 0x00000005
initprot 0x00000005
nsects 10
<snip>
然而，使用-l 0x93000重新运行命令给了我一个非常相似的结果：
However, rerunning the command with -l 0x93000 gave me a very similar result:
got symbolicator for /Users/arkaaito/Library/Developer/Xcode/Archives/2013-11-07/Zoomingo 11-7-13, 2.14 PM.xcarchive/Products/Applications/Zoomingo.app/Zoomingo, base address 4000
___lldb_unnamed_function2166$$Zoomingo (in Zoomingo) + 684
___lldb_unnamed_function2160$$Zoomingo (in Zoomingo) + 182
___lldb_unnamed_function6165$$Zoomingo (in Zoomingo) + 164
___lldb_unnamed_function6176$$Zoomingo (in Zoomingo) + 46
___lldb_unnamed_function6114$$Zoomingo (in Zoomingo) + 70
___lldb_unnamed_function1129$$Zoomingo (in Zoomingo) + 28
___lldb_unnamed_function2305$$Zoomingo (in Zoomingo) + 2446
___lldb_unnamed_function2302$$Zoomingo (in Zoomingo) + 3714
___lldb_unnamed_function476$$Zoomingo (in Zoomingo) + 512
___lldb_unnamed_function85$$Zoomingo (in Zoomingo) + 532
推荐答案
您必须使用 dSYM 包来调用 atos ，而不是应用程序包通常会删除符号！
You have to call atos with the dSYM package, not the app bundle since that normally has the symbols stripped!
所以电话是：
xcrun atos -l 0x97000 -arch armv7 -o myarchive.xcarchive/dSYMs/MyApp.app.dSYM 0x001357dc 0x00134446 0x00240cec 0x002416ea 0x0023e2de 0x000de724 0x00144f1a 0x00144336 0x000b1024 0x0009d464
这篇关于atos给出___lldb_unnamed_function的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
