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 Thomasesの返信とコメントに基づいて、私は古いXcodeバージョンのotoolでいくつかのテストを行い、Xcode 7.3の中でotoolを見つけました（これは、テストに便利なものです）。 .1はうまく動作しますが、テキストセクション全体を逆アセンブルしません。私はアップルにバグレポートを提出し、ここでの成果です：

エンジニアリングは、意図した以下の情報に をベースとして、この問題が動作することを決定しました：

コマンドotoolの実装では、（1）にXcodeの8に変更

システムにある古いotool-classic（1）のllvm-objdump（1）に基づいてください。

llvmコミュニティの場合、最初の既知のシンボルから逆アセンブリを開始する現在の動作は、llvmコミュニティ が望む動作です。

そして実際、ちょうどケンのように、必要に応じてotool-classic作品は（xcrun otool-classicが動作します）、すでに彼のコメントで指摘が、私はその返事に満足していないよので、私は今、LLVMプロジェクトでバグを報告します。