2

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

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

  1. このライブラリをアプリケーションにリンクして生成された実行可能ファイルをgdbで起動することにより、別のコンパイラチェーンを使用してWindowsで作成したこのライブラリのソースレベルのデバッグを行うにはどうすればよいですか。出来ますか？どうすればいいですか？このライブラリソースレベルのデバッグを有効にするためのコンパイラオプションがRVDSコンパイラツールチェーンにありますか？

  2. それらのソースファイルのウィンドウに存在するのとまったく同じフォルダー構造で、ソースファイルをLinuxにコピーする必要がありますか？

4

4 に答える 4

1

まず、GDB は関数にブレークポイントを設定するためのソースを必要としません。したがって、実際に何が起こっているかについてのあなたの説明はおそらく不正確です。中断したい関数が実際にバイナリに存在することを確認することから始めます。

  nm /path/to/app | grep function_desired

次に、ソース レベルのデバッグを行うには、GDB が理解できる形式のデバッグ情報が必要です。Linux では、これは通常、DWARFまたはを意味しSTABSます。RVDS コンパイラがそのようなデバッグ情報を出力しない可能性は十分にあります。その場合、ソース レベルのデバッグはできません。

于 2009-04-04T22:16:19.513 に答える
1

デバッグを有効にしてライブラリをビルドしましたか (-gオプション)? それがないと、行などを識別するのが困難になります。

于 2009-04-04T22:26:26.650 に答える
1

-fPIC がこの種の問題を引き起こすことがわかりましたが、私が見つけた唯一の回避策は、デバッグしたいときに -fPIC を使用しないことです。

于 2015-11-03T23:13:12.633 に答える
1

まったく同じディレクトリ構造が機能するかどうかを確認してみてください。実行可能ファイルのデバッグ情報でコンパイラが注釈を付けたディレクトリ構造がわからない場合は、いつでもdwarfdump(Linux で) 調べることができます。

于 2009-04-01T15:04:57.583 に答える