0

リスト項目 1 ～ 4 は、私が行った手順です。リスト項目 5 は問題を説明します リスト項目 6 は追加情報を提供します

  1. -gフラグを付けてc1.cと言うCソースコードをコンパイルしました。
  2. liba1.so という動的共有ライブラリもあり、そこにあるすべてのソース ファイルに対して -g でビルドされています。
  3. c1.o (c1.c オブジェクト コード) を liba1.so にリンクして、exe1 という実行可能ファイルを作成しました。

  4. 私はgdb exe1をします。c1.c のソースをステップ実行できます。c1 が共有ライブラリを呼び出すと、共有ライブラリ内の関数にブレークポイントを設定することもできます。

  5. ただし、関数をステップスルーしようとすると、「行番号情報がない関数 foo1 から終了するまでシングルステップ実行」と表示されますまた、通常は関数 foo1 に渡されたパラメーターの値を表示する必要がありますが、それは行いません. これは、いくつかの非常に大きな関数を含む共有ライブラリ内のすべての関数で発生するため、値を最適化することはできません

  6. 共有ライブラリと実行可能ファイルでobjdump -tを実行しました-シンボルテーブルが表示されます（関数にブレークポイントを設定できるという事実もこれをサポートしています）。また、ファイル c1.c で使用されている変数の値を確認できます。では、共有ライブラリ内のローカル変数の値を確認できるようにするにはどうすればよいでしょうか。共有ライブラリ "-O2 -std=gnu99 -Werror -fno-stack-protector -Wstack-protector --param ssp-buffer-size=1 -g -nostdinc" をコンパイルするために使用されるその他の引数を次に示します。info f を実行し、フレームのメモリアドレスを調べようとしても、情報は得られません。

少なくともトラブルシューティングを行うための提案を探しています。共有ライブラリに行番号情報がある場合、objdump (またはその他のユーティリティ) を使用して知ることができますか?

4

1 に答える 1

0

少なくともトラブルシューティングを行うための提案を探しています。

の最も可能性の高い理由no line number informationは、実際には行番号情報がないことです。その最も可能性の高い理由は、の 2 つのコピーがあり、liba1.so1 つはデバッグ情報があり、もう 1 つはデバッグ情報がなく、読み込み中です。実行時は後者。

最初のステップ:ロードされているものを正確(gdb) info sharedに教えてくれます。liba1.so

実際に でビルドしたばかりのバージョンである場合は-g、期待するデバッグ情報が含まれていることを確認する必要があります。これを行うための正確なコマンドはプラットフォーム固有です (そして、どのプラットフォームを使用しているかはわかりませんでした)。ELF プラットフォームでは、objdump -g liba1.soまたは動作readelf -w liba1.soするはずです。

-gコードがデバッグ情報を持たない一般的な理由の 1 つ-sは、リンク行に (strip) フラグが存在することです。リンク行に「迷子」フラグがないことを確認してください。一部のプラットフォーム-gでは、コンパイル時だけでなくリンク時にも使用する必要があります。

于 2013-04-26T14:54:07.520 に答える