問題タブ [dwarf]

私は、16 進アドレスをシンボリック関数名とバイナリ内のソース コード行番号に解決する必要があるユーティリティに取り組んでいます。このユーティリティは Linux on x86 で実行されますが、分析するバイナリは MIPS ベースの組み込みシステム用です。MIPS バイナリは ELF 形式で、シンボリック デバッグ情報に DWARF を使用します。

現在、objdump をフォークして、16 進アドレスのリストを渡し、出力を解析して関数名とソース行番号を取得することを計画しています。MIPS バイナリをサポートする objdump をコンパイルしましたが、動作しています。

別のプロセスをフォークすることなく、Python コードからネイティブに検索できるパッケージを用意したいと考えています。python.org で libdwarf、libelf、または libbfd についての言及も、dwarfstd.org での python についての言及も見つかりません。

どこかに利用可能な適切なモジュールはありますか？

これは私が時々遭遇する状況です：

仮想アドレッシングを使用しない組み込みシステムの場合、C または C++ コードからデバッグ情報を含めてコンパイルされた実行可能ファイルがあります。通常、COFF または ELF/DWARF (これら 2 つを混同しています) 形式です。

実行時に、PC で、名前が指定された変数のアドレスを特定したいと考えています。（例：「foo.bar [7] .baz」）これにより、組み込みシステムで変数の値を読み書きできます（この質問の範囲を超えるデバッグプロトコルが与えられます）。明らかに、スタックベースまたはヒープベースの変数は静的アドレスを持っていないため、アウトです。

TI の 2800 シリーズ DSP 用に TI のコンパイラから COFF ファイルを解析するために、C++ でこれを行う前に、これを行ったことがあります。1 つまたは 2 つの他のプロセッサの実行可能ファイルで同じ問題に直面しているため、このようなことを行う Java ライブラリが既に存在するかどうか疑問に思っていました。

更新: (2009 年 11 月 18 日) 有望な手がかりです!

Eclipse CDT ELF パーサーを使用した人はいますか?

( http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.cdt.doc.isv/reference/api/org/eclipse/cdt/core/model/IBinary.htmlを参照) javadoc pgs の

TI の Code Composer 4 (Eclipse ベース) はこれを使用しているようです。そのため、ドキュメントがどこにあるかがわかれば、それを使用して問題を解決できるようです。

誰かがDWARFファイルを読み取って、ファイル名、行番号、関数名の詳細を教えてくれるプログラムを書くのを手伝ってくれませんか。

ELFファイルのデバッグ情報をDWARF形式で読み取るための優れたクロスプラットフォームライブラリに関する推奨事項はありますか？PythonプログラムでDWARFデバッグ情報を読みたいのですが。

私はiPhoneアプリケーションで作業してきましたが、dSYMファイルの生成でセグメント障害が発生するという問題がありました。

GenerateDSYMFile /Users/kaom/Projects/build/Release-iphoneos/NodeAppGen.app.dSYM /Users/kaom/Projects/build/Release-iphoneos/NodeAppGen.app/NodeAppGen cd / Users / kaom / Projects / Apps / NodeAppGen setenv PATH "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin" / Developer / usr / bin / dsymutil / Users / kaom / Projects / build / Release-iphoneos / NodeAppGen.app / NodeAppGen -o /Users/kaom/Projects/build/Release-iphoneos/NodeAppGen.app.dSYM

コマンド/Developer/ usr / bin/dsymutilが終了コード11で失敗しました

このバグを、アプリケーションのInfo.plistファイルのエラーまで追跡しました。

それ以外の

私は持っていた

私の知る限り、dSYMファイルの生成は実行可能ファイルにのみ依存しており、plistファイルは実行可能ファイルに影響を与えないはずです。だから私の質問は、なぜこれがdSYMファイルの生成を壊したのかということです。

*nix で C++ をコンパイルしていますが、a) プログラムの任意の時点で、b) シグナル中、特に SIGSEGV 中にスタック ダンプを生成したいと考えています。

Google は、おそらく ptrace がその仕事のためのツールであると言っていますが、スタックをたどるわかりやすい例を見つけることができません。返信先住所を取得することはできますが、次の返信先住所はどうでしょうか。そして、その時点で関数のシンボリック名を抽出するのはどうですか? ドワーフと関係ある？

ここからどこに行くべきか教えていただければ、どうもありがとうございます。

ソースレベルのデバッガーに取り組んでいます。elf形式で利用可能なデバッグ情報。「ステップオーバー」をどのように実装できますか？問題は「Point1」にありますが、とにかく次のソース行を待つことができます（.debug_lineテーブルから読み取ります）。

ありがとう

gdb と libbfd を使用して、elf ファイルからグローバル変数情報を取得し、表示しています。libbfd から次のデータを取得できます: グローバル変数の名前、アドレス、およびサイズ。gdb と gdb\MI (ptype、whatis、-var-create & -var-list-children) を使用して、変数とその子の型を取得します。

すべての子の親からアドレス\サイズ\オフセットを取得するにはどうすればよいですか?

例えば

この型の変数 A がアドレス 0x000100 にある場合、A.count がサイズ 0x1 の 0x000100 にあり、A.time がサイズ 0x1 の 0x000101 にあることを示したいと思います。

編集: gdb は DWARF 情報を読み取ることができると読みましたが、gdb からこの情報を取得する方法がわかりません。

ある形式のデバッグ シンボルを、GDB で使用できる別の形式に変換することを目的としたツールを作成しようとしています。これは退屈で潜在的に複雑なプロジェクトのように思えるので、どうやって取り組むべきか正確にはわかりません。

最初は、borland コンパイラから出力された Turbo Debug Symbol テーブル (TDS) を stabs や dwarf 形式のようなものに変換することを目指しています (私の研究では dwarf が好まれているようです)。しかし、理想的には、ツールを簡単に拡張できるように設計して、後で他の形式も変換できるようにしたいと考えています。たとえば、codeview4 またはおそらく pdb です。

これを作成する主な動機は次のとおりです。

• 相互運用性。外部デバッグ形式を gdb が動作する形式に変換できれば、gcc 以外の別のコンパイラからコンパイルされたバイナリでソースレベルのデバッグが可能になります。これは、gdb をバックエンドとして使用するフロントエンド デバッグ インターフェースも同様に機能することを意味します。
• 他のツールは存在しません。同様のツールをグーグルで検索しましたが、見つけた最も近いものはtds2dbgです。しかし、それは私が探しているものではありません。

現時点で取り組まなければならないこと：

• TDS デバッグ形式を理解できるデバッグ フック APIを既に持っています。これを使用して、変換元のソース形式から必要な情報を取得できます。
• このプロジェクトの範囲では、これを win32 環境で動作させることに主に関心があります。私があまり気にしていない他のプラットフォームとツール。
• 変換先の dwarf デバッグ形式。これは、私にはまったくなじみがありません。以前に MinGW のような gcc 移植コンパイラを使用し、dwarf 形式の gdb でそれらをデバッグしました。しかし、この形式が Windows でどのように実装されているかはわかりません。

最後に気になる点です。ドワーフ仕様のドキュメントを読んでいますが、それがどのように機能するかを本当に理解して理解するのに苦労しています。そこには非常に多くの詳細がありますが、同時に、ELFをネイティブに使用しないプラットフォーム上のオブジェクトファイルとイメージファイルにdwarfがどのように実装されるかについての詳細はありません-つまり、Windowsが使用するPE-COFF形式. ドキュメンテーションも非常に無味乾燥で、長い文章は理解しにくく、図やイラストはまばらです。私はlibDwarfと呼ばれる API に出会いました。これは、ドワーフの解釈からほとんどの解析作業を取り除くはずです。問題は、私はまだそれを構築しようとしていることであり、それがどのように機能するかはまだわかりません.

ビルドする必要があるものを完全に理解していないため、まだコードを書いていません。ドワーフは複雑なので、ドワーフをどのように扱うかが最大の課題になると思います。ウィンドウの下でドワーフがどのように機能するかについての情報をグーグルで検索しても、役立つものは何も見つかりませんでした。たとえば、PE 実行可能イメージ ファイル内に dwarf を含めるために必要な「グルー」コードに関する情報はありません。ドワーフセクションはどのように正確に配置されていますか? 各セクションのヘッダー情報はありますか? GDB は明らかに、「生の」ドワーフ デバッグ ファイルをそのまま使用するだけではありません。では、gdb は、デバッグ ファイルを操作できるようにするために、デバッグ ファイルがどのような形式であると想定しているのでしょうか。

私の質問は、どうすればそのようなプロジェクトを開始できるでしょうか? さらに重要なことは、どうしても問題に行き詰まってしまった場合、どこに助けを求めることができるかということです。

Windows で libdwarf API をビルドしようとしていますが、次のコンパイル エラーが発生します。

すべてのヘッダー ファイルとソース ファイルを検索しましたが、私が知る限り、それらが定義されている場所は見つかりませんでした。これらは unix/linux 固有の定義ですか? Windows でこれらのエラーを解決するにはどうすればよいですか?

ありがとう