为什么otool要截断我的反汇编输出？

Question

当我运行这个命令时

otool -t binary

otool将正确转储binary的文本部分。例如。

0000000100002100   55 48 89 e5 41 56 53 48 8b 35 32 24 54 00 4c 8b 
:

但是当我运行这个命令时：

otool -tvV binary

otool跳过了文本部分的大部分内容：

00000001003a32ce pushq %rbp
:

前3805646字节只是简单的跳过而不是拆卸。如果我在lldb中打开二进制文件，我就可以在跳过的地址上反汇编代码。

有没有人有过类似的经历？otool是否有一个内部大小限制，并截断超出该限制的部分？有没有人发现过一种可以免费使用的类似工具？

我试着用lldb解压缩整个二进制文件

lldb binary
(lldb) dis -s 0x100002100 -e ...

将-e设置为文本部分中最后一个字节的地址，但这也不起作用。实际上，lldb在分解大约5000字节的文本部分后停止输出。

Answer 1

我以前见过这种情况，我认为otool跳到了第一个符号(令人恼火)。如果您使用nm -n binary，是在00000001003a32ce上定义的第一个符号

Xcode附带了另一个名为otool-classic的工具，它似乎分解了整个文本段。想必，它是重写之前的otool的旧版本或类似的东西。虽然它获得了整个文本段，但它在其他方面可能不那么有特色(例如解码对选择器或字符串的引用)。要调用它，可以使用xcrun otool-classic <args>。

在我的测试中，您还可以使用早期版本的Xcode附带的otool版本。Xcode 7.3.1和Xcode 6.4中的代码没有这个问题。(这些是我碰巧有方便测试的。其他的也可能起作用。)

Answer 2

基于Ken的回复和评论，我从旧的Xcode版本中用otool进行了一些测试，发现Xcode 7.3.1中的otool工作得更好，但也不会分解整个文本部分。我向苹果提交了一份bug报告，结果如下：

工程部已经确定，这一问题的行为是基于以下信息： otool(1)的实现在Xcode 8中更改为基于llvm-objdump(1)，而不是老的otool-经典(1)，它仍然在系统上。 对于llvm社区来说，当前从第一个已知符号开始分解的行为就是llvm社区所希望的行为。

事实上，otool-classic按需要工作(xcrun otool-classic会工作)，就像Ken在他的评论中指出的那样，但是我对这个答复不满意，所以我现在将在LLVM项目中提交一个bug。