問題タブ [dwarf]

バイナリをライブラリと動的にリンクする場合、再配置情報を使用して、さまざまな ELF オブジェクトの変数/関数をバインドします。ただし、DWARF は再配置の影響を受けません。デバッガーはグローバル変数をどのように解決するのでしょうか?

グローバル変数を定義する liba.so (ac) があるとします (GCC または Clang で GNU/Linux を使用):

liba.so (bc) に対してリンクされたプログラム b:

「foo」は liba.so でインスタンス化されると予想していますが、実際には liba.so と b の両方でインスタンス化されています。

(b と lib.so の両方で) 使用される foo 変数は、liba.so ではなく b の .bss にあります。

foo 変数は 2 回インスタンス化されます。

• liba.so で 1 回 (このインスタンスは、プログラム b とリンクされている場合は使用されません)

• b で 1 回 (このインスタンスは b で他のインスタンスに使用されます)。

(変数が実行可能ファイルでインスタンス化される理由がよくわかりません。)

DWARF 情報の b には (予想どおり) 宣言のみがあります。

場所は liba.so にあります。

このアドレスは、liba.so (.data) 内の foo の (使用されていない) インスタンスの場所です。

• foo グローバル変数の 2 つのインスタンス (liba.so の on と b の 1 つ) になります。
• DWARF で表示できるのは最初の 1 つだけです。
• 2 番目の 1 つだけが使用されます。

デバッガーは foo グローバル変数をどのように解決することになっていますか?

C/C++ ソース ファイル内の任意の要素について、コンパイルされた実行可能ファイル内の対応するメモリ位置を特定できるようにしたいと考えています。デバッグを使用してコンパイルし、結果の DWARF 情報を使用することは、これに向けて大いに役立ちますが、私の目標にはほど遠いものです。GCC は、行番号のみで DWARF .debug_line 情報を生成し、列番号を 0 のままにしているようです! DWARF仕様で列番号を指定できるのは奇妙に思えますが、GCCは列番号を生成していないようです。

不足しているものはありますか? おそらく、デバッグ情報に列が必要であることを GCC に知らせるための構成またはコマンド ライン パラメータがありますか? それとも、私の目標を達成するためのまったく別の方法があるのでしょうか?

以下は、DWARF に列番号がないことを示す簡単なコードです。

これを次のようにコンパイルします。

次に、次のコマンドで DWARF 情報を表示します。

出力は次のとおりです。

システムにバイナリがインストールされており、特定の関数の逆アセンブルを確認したいと考えています。を使用することをお勧めしobjdumpますが、他の解決策も受け入れられます。

この質問から、境界アドレスさえわかれば、コードの一部を逆アセンブルできる可能性があることがわかりました。この回答から、分割されたデバッグ シンボルを 1 つのファイルに戻す方法を学びました。

しかし、その単一のファイルを操作し、すべてのコードを逆アセンブルしても (つまり、開始アドレスまたは停止アドレスはなく、単純な-dパラメーターを にobjdump)、そのシンボルはどこにも表示されません。問題の関数が静的である限り、これは理にかなっているため、エクスポートされません。それにもかかわらず、valgrind関数名を報告するため、どこかに保存する必要があります。

デバッグ セクションの詳細を見ると、その名前が.debug_strセクションに記載されていますが、これをアドレス範囲に変換できるツールがわかりません。

LLVM の最適化中に DWARF のデバッグ情報を保持しようとしています。質問は、LLVM のすべての命令のデバッグ情報を何らかの方法で挿入できますか? LLVM は、すべての最適化パスを実行するときにこれらの情報を保持し、DWARF 注釈付きの LLVM 最適化 IR をダンプしますか?

これが機能する場合、バックエンド (もちろんこれらのデバッグ情報をサポートする) に、ソース コードでデバッグ可能な (多かれ少なかれ最適化により) 最終的なエンド コードを生成させることができると思いますが、正しいですか?

私は、かなり複雑な静的分析と他のプログラムの動的トレースを行うソフトウェアを作成しています。.debug_lineこのプログラムは、 DWARF セクションからの行/列情報を含む、多くの静的 DWARF 情報を使用してトレースを支援します。このプログラムが必要な精度を持つためには、DWARF デバッグ情報に取り込まれる、きめ細かく正確な行番号と列番号の情報が必要です。I を使用すると、オプションを一緒にclang使用して行と列の情報を強制的に入力できます。-g -Xclang -dwarf-column-info

ただし、clang が十分に細かい列情報を生成しない場合があります。1 つの特定のインスタンスは forforループです。次のサンプルプログラムを取り上げます。これを と呼びますsource01.c。

次のようにコンパイルできます。

実行可能ファイルを生成しますa.out。次にdwarfdump、行/列の情報がどのように取り込まれたかを調べるために使用します。

この.debug_lineセクションを見ると、この実行可能ファイルのデバッグ情報に含まれるすべての行/列のペアが表示されます。

ご覧のとおり、 に対応するペア (5,10) と に対応するint i=0;ペア (5,27) があり++iます。ただし、 に対応するペア (5,19) もあると予想 (および必要) しますが、存在しi < 10ません。実行可能ファイルの命令を で検査し、objdump実際に比較に対応する命令があることを確認しましたi < 10(したがって、単純に「最適化されていない」わけではありません)。

なぜclangがこの情報を入力しないのかについての直感はありますか? または、clangよりきめ細かい列情報を強制的に生成する方法はありますか? clang生成されるAST にはclang、それ自体とソース コードの行および列との間のマッピングが非常にきめ細かく設定されているため、この機能が必要と思われます。

ありがとうございました。

次の関数定義を含む C モジュールを想定します。

ソースファイルをgcc -gでコンパイルした際に得られるdwarf情報(結果の.o-fileに埋め込まれている)から、パラメータ'a'の実配列サイズ情報'6'を抽出することは可能でしょうか?

オブジェクト ファイルに 'readelf -wi' を適用して dwarf 情報を取得しましたが、固定配列サイズを導出するための情報が見つかりません。

アプリのビルド時に生成される dsym ファイルの構造は何ですか。DWARF デバッグ情報が含まれていることは知っていますが、dsym ファイルとは何ですか。その中のDWARF情報を読みたい。

デバッグ セクションのみを含む単なる Mach-O バイナリ ファイルですか? pyelftoolELF ファイルのデバッグ セクションで DWARF 情報を読み取る のような DWARF 解析ツールに渡すにはどうすればよいですか。

dsym ファイルのセクションを印刷するために使用objdump -hします (.dsym ファイルはパッケージです。パッケージ内のバイナリ ファイルを参照するだけです)。

C++ プロジェクトのデバッグ情報をリモートの場所に転送してテストする方法を作成しようとしています。現在の開発サイクルでは、コードに小さな変更を加えると、バイナリ全体 (サイズは 100 MB で、ほとんどがデバッグ情報) を転送する必要があります。

現在、これに対処するための私のアプローチは、-gsplit-dwarf を使用してオブジェクト ファイルからデバッグ情報を分割し (デバッグ情報なしのサイズは私の接続で管理可能です)、現在実行中のビルドのコピーに対してデバッグ ファイルを比較することです。リモートボックス。

目的は、プロジェクトのデバッグ ファイル用の一連のパッチを用意して、新しいコードをリモート ロケーションでデバッグできるようにすることです。リモートの場所とローカル マシン間の接続は低速であるため、パッチのサイズを最小限に抑えることが最も重要ですが、ツールの実行時間とのバランスを取る必要もあります。可能性のある解決策として bsdiff と xdelta を調べたところ、xdetla は高速ですが大きすぎ、bsdiff はサイズの点で完璧ですが、実行時間とメモリ要件が希望よりも少し高いという難問に遭遇しました。

不足しているツールやアプローチはありますか、それとも間違った方法で進んでいますか? おそらくbsdiffとxdeltaに代わるものはありますか? gbdserver のようなツールは、実際のデバッグに関するいくつかの要件のために、この状況では機能しないことを私は知っています。bsdiff を変更すると、パフォーマンスが向上しますか? 実際、私が使用しているアプローチが適切である場合、ビルドのコピーをリモート マシンに保持して比較するための良い方法は何でしょうか。

ドワーフ情報から DW_AT_data_member_location 属性値を出力しようとしていますget the member variables offset from a struct nameが、ヘルパー関数が機能していないようです。

からの dwarf_info は次のとおりですobjdump。

属性コードは取得できますが、属性値は取得できません:

この変数の型は何ですか? その値を取得する方法は? ここでどのヘルパー関数が機能しますか?

私はこのコードを持っています:

コンパイルしますg++ -g main.cpp（私のOSでは272が出力されます）

その後、objdump --dwarf=info a.out次のデバッグ情報エントリ (ダイ) を実行して確認しますostream。

実際ostreamには、 Die の typedef にbasic_ostream<char, std::char_traits<char>> サイズ ( ) の属性が含まれていないだけで、そのDW_AT_byte_size理由がわかりません。実行可能ファイルには ostream クラスの他のダイはありませんが、コンパイラはそのクラスのサイズを知っている必要があります (サイズは で出力されますsizeof)。だから私の質問はostream、ドワーフ情報からクラスの適切なサイズを取得するにはどうすればよいですかobjdump?