PS英語は私の母国語ではありません。タイプミスがあることをご了承ください。
私は（おそらく）基本的な主なアイデアを理解しますシンボルELFファイルから動的リンクから。
教科書を参照すると、.soなどに動的にリンクする必要がある場合は、リンク先の関数名が必要です（たとえば、関数についてのみ話している場合）。その後、ローダーはターゲットの実際の位置を見つけるためにアクションを実行します。次に、別の操作を実行してロードします。関数の名前は、私たちがシンボルと呼ぶことができるものの名前です。
しかし、デバッグ、次は私を混乱させます。
Arch Linuxにpwndbg（GDB用プラグイン）をインストールしようとしましたが、いくつかの問題が発生しました。次のガイドラインに従ってください。 [1][2]、問題を解決しました。しかし、解決策がどのように機能するかはよく理解されていません。
プラグイン作成者でもあるSolution Providerのポスターによると、Archのglibcには「デバッグシンボル」がないので手動でインストールする必要がありますが、Ubuntuのglibcには「デバッグシンボル」があるのでインストールする必要はありません。手動で。
だからここに私を混乱させるいくつかの質問があります。
私はなぜそれを行うことができますか？インストールするglibc などの lib シンボルです。 .so(ELF) ファイルに記号がなく、その中に記号を入れた場合。 ELFは相対ファイルオフセットに基づいているため、ELFファイル形式が破損する可能性があります。そうではありませんか？それで何をしましたか？インストールする実際には？それとも、この文脈では、「シンボル」は実際に何を意味しますか？
gcc -g（「gcc -gはGDBデバッガで使用するデバッグ情報を生成します」）実際に生成されるものは何ですか？ （私がインストールしたもの）同じですか？ 「デバッグ情報を生成する」必要がある場合は、ソースコードが必要です。そうですか？
ベストアンサー1
多くのディストリビューションで（ダーバン、Ubuntu、Fedoraなどがありますが、私が知っている限り、Archはそうではありません。対応するwikiページ）、プログラムはデバッグ情報（下記参照）で構築されていますが、デバッグ情報は優れた別のファイルとして。これらの個々のファイルは、デバッグパッケージおよび/またはデバッグ情報サーバーを介して提供され、デバッグに役立つファイルと共にインストールできます。
gcc -g保存された情報を使用すると、デバッガはコンパイラによって生成されたバイナリコードからソースコードに戻ることができます。この情報を使用すると、デバッガは実行可能ファイルまたはメモリの場所を適切なソースコードに変換できます。例えば、変数の位置を関連宣言に連結し、実行コード内の位置を関連ソースコード行に連結することができる。
マイケルJ.の願望DWARF デバッグ形式の紹介デバッグ情報の機能の良い説明です。また、見ることができます/usr/lib/.build-id/dirの目的は何ですか？