実行中のプロセスのデバッグ シンボルをロードするにはどうすればよいですか?

php エディタ Xiaoxin では、実行中のプロセスのデバッグ シンボルを読み込む方法を紹介します。ソフトウェア開発プロセスにおいて、デバッグは非常に重要なリンクです。実行中のプロセスで問題が発生した場合、デバッグ用にデバッグ シンボルをロードする必要があります。デバッグ シンボルにはコードのシンボル情報が含まれており、デバッグ中に問題をより正確に特定できるようになります。この記事では、デバッグを容易にするために、実行中のプロセスのデバッグ シンボルを読み込む方法を詳しく説明します。

質問の内容

多くのマシンで実行される C アプリケーションがありますが、時々 1 つのインスタンスに問題が発生し、奇妙な動作をすることがあります。残念ながら、このようなことはほとんど起こりません。これらの製品インスタンスは高度な最適化 (-march=XXX -Ofast) を使用してコンパイルされており、デバッグ シンボルが含まれていないため、ステータスを分析するためのデバッガーを簡単に接続することはできません。

しかし、同じフラグと -g3 を使用してアプリケーションを再度コンパイルできるはずです。そうすれば、symbol-file application_executable_with_debug_symbols を使用してそれを gdb にロードできるはずです。ただし、これを実行してもブレークポイントは起動しません。

実行中のアプリケーションにデバッガーを接続し、デバッグ シンボルを読み込む別の方法はありますか?それとも（明らかに）何か間違ったことをしているのでしょうか？

ありがとう

回避策

ベスト プラクティスは、デバッグ シンボルを使用してアプリケーションをビルドし、結果のバイナリをデバッグ用に保持し、strip -g app.debug - o app を実行することです。 release を実行し、ストリップされたバイナリを運用環境で実行します。

異常な動作をしているインスタンスを見つけた場合は、完全なデバッグ バージョンをターゲット マシンにコピーし、 gdb -ex 'attach $PID' app.debug を実行できます。これで、完全なデバッグ シンボルが完成しました。

アプリケーションを再度コンパイルしても機能しない最も可能性の高い理由は、異なるシンボルを持つ新しいバイナリを取得することです (nm app.debug と nm app.release を比較してください)。そして、最も可能性の高い理由 (GCC を使用している場合) は、app.release をビルドする際にいくつかの最適化フラグを省略したか、わずかに異なるソースを使用したことです。Must このメソッドが成功するには、まったく同じフラグ (および -g を追加) とまったく同じソースを使用します。

以上が実行中のプロセスのデバッグ シンボルをロードするにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。