ライブラリのソースレベルのデバッグを行うには

Question

次の設定があります。私の作業セットアップでは、Windowsホスト上でARMコンパイラReal View Developer Suite（RVDS）3.2を扱っていますが、どのホスト上の他のCコンパイラでもこの状況が一般的である可能性があります。

WindowsホストでRVDS 3.2コンパイラツールチェーンを使用してCコードのARMライブラリ（静的ライブラリ - .aファイル）をビルドします。次に、このライブラリをLinuxホスト上のARM-Linuxコンパイラツールチェーンを使用してアプリケーションにリンクし、ARM実行ファイルを取得します。今、gdbを使ってこの生成されたARM実行可能ファイルをデバッグしようとすると、リンクされているライブラリに存在するいくつかの関数にブレークポイントを設定しようとすると、gdbはブレークポイントをソースを見つけることができません。そこで、実行可能ファイルが存在するLinuxフォルダにライブラリを作成するために使用されたすべてのソースファイル（*。c）を手動でコピーしました。それでもgdbはブレークポイントを設定できません。で、私は、アプリケーションにこのライブラリをリンクすることによって生成された実行ファイルを起動して別のコンパイラチェーンを使用してWindows上で作成し、このライブラリのソースレベルのデバッグを行うことができますどのように

1. ： は、だから今、私は思考を開始しましたgdb。出来ますか？どうしたらいいですか？このライブラリソースレベルのデバッグを有効にするために、RVDSコンパイラツールチェーンにコンパイラオプションはありますか？

2. ソースファイルをWindowsのソースと同じフォルダ構造でlinuxにコピーする必要がありますか？

Answer 1

正確に同じディレクトリ構造を模倣するかどうかを試すことができます。コンパイラが実行可能ファイル内のデバッグ情報に注釈を付けたディレクトリ構造がわからない場合は、いつでもdwarfdump（Linux上）で見ることができます。

Answer 2

まず、GDBはではありません。には、関数にブレークポイントを入れるソースが必要です。実際に起こっていることについてのあなたの記述はおそらく不正確かもしれません。 、

nm /path/to/app | grep function_desired 

セカンドソースレベルのデバッグを行うために、GDBは、GDBが理解できるフォーマットでデバッグ情報を必要とする：私はあなたが壊したく関数はバイナリであり、実際にあることを確認することによって開始します。 Linuxでは、これは一般にDWARFまたはSTABSを意味します。 RVDSコンパイラがそのようなデバッグ情報を出力しない可能性があります。もしそうなら、ソースレベルのデバッグは不可能です。

Answer 3

デバッグを有効にしてライブラリをビルドしましたか（-gオプション）？これがなければ、回線などを特定するのが難しくなるでしょう。

Answer 4

私は、このような問題が発生することを発見しましたが、私が発見した唯一の回避策は、デバッグするときに-fPICを使用しないことです。