問題タブ [dwarf]

私はまだ処理方法がわからないタスクを与えられたので、これを求めています。おわかりのように、非常に古い Linux カーネルを実行している仮想マシンで従来の a.out プログラムを実行できる状況になっています。ネイティブ MinGW gdb でプログラムを何らかの形でデバッグしたいと考えています。UNIX の a.out ファイルを仮想マシン上で実際に実行しながら、a.out ファイルをデバッグ シンボルを含む PE ファイルに変換し、それを GDB に送信して処理することが提案されています。VM で使用されている GCC のバージョンが非常に古いため、a.out ファイルに付属する使用可能なデバッグ シンボルは STABS のみです。

STABS デバッグ情報を PE ファイルに追加できることを理解しています。GCC がそれを行い、STABS が MinGW GDB で動作するという結論に達するのに十分な包括的な実験をobjdump行いました。gdbでは、どうすればそれを達成できますか？GCC はどのようにアプローチしましたか?

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

私はアセンブリ レベルの人間が話せるプログラミング言語を nasm で書いています。Dwarf のデバッグは、Dwarf の開発に不可欠なコンポーネントであることに気付きました。

後でセルフホスティングにするためには、ELF にコンパイルするだけでなく、Dwarf をサポートしてデバッグを実行可能にする必要があります。ELF については、ELF ヘッダーを作成する方法の素晴らしい nasm の例があり ます http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html http://blog.markloiseau.com/2012/05/tiny -64-bit-elf-executables/

gdb で動作するために必要な DWARF セクションを含む、DWARF に似たものが存在するか、または作成できるかどうか疑問に思っています。このような例を使用すると、ほとんどが C に言及しているやや不可解なドキュメントを参照するよりも、DWARF を理解するのがはるかに簡単になります。機能ごと www.ibm.com/developerworks/library/os-debugging/

いずれにせよ、たまたま nasm hello world dwarf の例を作成できれば、dwarf 形式がよりアクセスしやすくなるため、世界はそれを高く評価すると確信しています。おそらく、誰かがそれを fasm や nasm 以外のアセンブラで実装できるようになるでしょう。

Qt (windows)にインストールする方法について何時間も調査 (および試行) した後id3lib、成功しなかったため、TagLib のライブラリを使用することにしました。

このチュートリアルに従って、互換性のあるバージョンの Qt 用の taglib をビルドしましたが、まだ別の問題があります (完全なログはこちら):

CMake では、configure>を行いましたMinGW Makefiles。

誰でもそれを修正する方法を教えてもらえますか?

環境：

• Windows 7 (64 ビット);
• CMake 2.8.12.1;
• タグライブラリ 1.9.1;
• GCC 3.4.5;
• Qt 5.1.1。

質問 1: 行 8 が実行されるとき、%esp と %ebp の両方が CFA - 4 に等しく、スタックに格納された戻りアドレスを指していると推測します。そうですか？

アセンブリ：

C コード:

質問 2:コードに.cfi_offset 5, -8を挿入する必要がある理由がわかりません。.cfi_def_cfa_register 5、.cfi_restore 5および.cfi_def_cfa 4, 4も同様です。これらのディレクティブの使用方法を見つけました：

• .cfi_offset レジスター、オフセット
• レジスタの前の値は、CFA からのオフセット、オフセットに保存されます。
• .cfi_def_cfa_register レジスター
• .cfi_def_cfa_register は、CFA を計算するためのルールを変更します。これからは、古いものに代わってレジスターが使用されます。オフセットはそのまま。
• .cfi_restore レジスタ
• .cfi_restore は、.cfi_startproc によって追加されたすべての初期命令が実行された後、レジスタのルールが関数の開始時と同じになったことを示しています。
• .cfi_def_cfa レジスター、オフセット

• .cfi_def_cfa は、CFA を計算するためのルールを次のように定義します。レジスタからアドレスを取得し、それにオフセットを追加します。

  ですから、1#、2#、3# という数字がそれぞれどのレジスタを表しているのか知りたいのです。

バイナリをライブラリと動的にリンクする場合、再配置情報を使用して、さまざまな 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 情報を表示します。

出力は次のとおりです。