GCC -fPICオプション

コード生成規約に関するGCCのオプションについて読みましたが、「位置に依存しないコード（PIC）を生成する」の機能を理解できませんでした。例を挙げて、どういう意味か説明してください。

位置独立コードとは、生成されたマシンコードが特定のアドレスに配置されていることに依存しないことを意味します。

たとえば、ジャンプは絶対ではなく相対として生成されます。

疑似アセンブリ：

PIC：これは、コードがアドレス100でも1000でも機能します

100: COMPARE REG1, REG2
101: JUMP_IF_EQUAL CURRENT+10
...
111: NOP

非PIC：これは、コードがアドレス100にある場合にのみ機能します

100: COMPARE REG1, REG2
101: JUMP_IF_EQUAL 111
...
111: NOP

編集：コメントに応じて。

コードが-fPICでコンパイルされている場合は、ライブラリに含めるのに適しています。ライブラリは、メモリ内の適切な場所から別のアドレスに再配置できる必要があります。ライブラリが優先するアドレスに別のライブラリが既にロードされている可能性があります。

すでに言われていることをもっと簡単に説明しようと思います。

共有ライブラリが読み込まれると、ローダー（実行するプログラムを読み込むOS上のコード）は、オブジェクトが読み込まれた場所に応じて、コード内の一部のアドレスを変更します。

上記の例では、非PICコードの「111」は、最初にロードされたときにローダーによって書き込まれます。

共有されていないオブジェクトについては、コンパイラーがそのコードに対していくつかの最適化を行うことができるため、そのようにすることが必要な場合があります。

共有オブジェクトの場合、別のプロセスがそのコードに「リンク」する場合は、同じ仮想アドレスに読み取る必要があります。そうしないと、「111」は意味がありません。しかし、その仮想空間はすでに2番目のプロセスで使用されている可能性があります。

共有ライブラリに組み込まれているコードは通常、位置に依存しないコードである必要があります。これにより、共有ライブラリを（多かれ少なかれ）メモリ内の任意のアドレスに簡単にロードできます。この-fPICオプションにより、GCCがそのようなコードを確実に生成します。

さらに追加しています...

すべてのプロセスに同じ仮想アドレス空間があります（Linux OSでフラグを使用して仮想アドレスのランダム化を停止した場合）（詳細については、アドレス空間レイアウトのランダム化を無効にして再度有効にしてください）

したがって、共有リンクのない1つのexe（仮定のシナリオ）の場合、害を及ぼすことなく、常に同じ仮想アドレスを同じasm命令に与えることができます。

しかし、共有オブジェクトをexeにリンクする場合、共有オブジェクトがリンクされた順序に依存するため、共有オブジェクトに割り当てられた開始アドレスはわかりません。リンク先のプロセスに応じて異なる仮想アドレス。

したがって、1つのプロセスが独自の仮想空間で0x45678910として.soに開始アドレスを与えることができ、同時に他のプロセスが0x12131415の開始アドレスを与えることができ、相対アドレス指定を使用しない場合、.soはまったく機能しません。

したがって、常に相対アドレッシングモードを使用する必要があるため、fpicオプションを使用する必要があります。

動的ライブラリ内の関数へのリンクは、ライブラリが読み込まれたとき、または実行時に解決されます。したがって、プログラムを実行すると、実行可能ファイルと動的ライブラリの両方がメモリに読み込まれます。固定アドレスが同じアドレスを必要とする別の動的ライブラリと競合する可能性があるため、動的ライブラリがロードされるメモリアドレスを事前に決定することはできません。

この問題を処理するために一般的に使用される2つの方法があります。

1.移転。コード内のすべてのポインタとアドレスは、必要に応じて、実際のロードアドレスに合わせて変更されます。再配置は、リンカーとローダーによって行われます。

2.位置に依存しないコード。コード内のすべてのアドレスは、現在の位置を基準にしています。Unixライクなシステムの共有オブジェクトは、デフォルトで位置に依存しないコードを使用します。これは、特に32ビットモードでプログラムが長時間実行される場合、再配置よりも効率的ではありません。

「位置に依存しないコード」という名前は、実際には次のことを意味します。

• コードセクションには、再配置が必要な絶対アドレスは含まれず、自己相対アドレスのみが含まれます。したがって、コードセクションを任意のメモリアドレスにロードして、複数のプロセス間で共有できます。

• データセクションには書き込み可能なデータが含まれていることが多いため、データセクションは複数のプロセス間で共有されません。したがって、データセクションには、再配置が必要なポインタまたはアドレスが含まれる場合があります。

• Linuxでは、すべてのパブリック関数とパブリックデータをオーバーライドできます。メイン実行可能ファイル内の関数が共有オブジェクト内の関数と同じ名前である場合、メインからバージョンが呼び出されるときだけでなく、共有オブジェクトから呼び出されるときも、メインのバージョンが優先されます。同様に、メインのグローバル変数の名前が共有オブジェクトのグローバル変数と同じである場合、共有オブジェクトからアクセスされた場合でも、メインのインスタンスが使用されます。

このいわゆるシンボル挿入は、静的ライブラリの動作を模倣することを目的としています。

共有オブジェクトには、この「オーバーライド」機能を実装するために、プロシージャリンケージテーブル（PLT）と呼ばれるその関数へのポインタのテーブルと、グローバルオフセットテーブル（GOT）と呼ばれるその変数へのポインタのテーブルがあります。関数とパブリック変数へのすべてのアクセスは、このテーブルを通過します。

ps動的リンクを回避できない場合、位置に依存しないコードの時間のかかる機能を回避するさまざまな方法があります。

あなたはこの記事からもっと読むことができます：http : //www.agner.org/optimize/optimizing_cpp.pdf

すでに投稿されている回答へのマイナーな追加：位置に依存しないようにコンパイルされていないオブジェクトファイルは再配置可能です。これらには、再配置テーブルのエントリが含まれています。

これらのエントリにより、ローダー（プログラムをメモリにロードするコード）が絶対アドレスを書き換えて、仮想アドレス空間の実際のロードアドレスを調整できます。

オペレーティングシステムは、メモリに読み込まれた「共有オブジェクトライブラリ」の単一のコピーを、同じ共有オブジェクトライブラリにリンクされているすべてのプログラムと共有しようとします。

コードアドレススペース（データスペースのセクションとは異なり）は連続している必要はありません。また、特定のライブラリにリンクするほとんどのプログラムには、かなり固定されたライブラリ依存関係ツリーがあるため、これはほとんどの場合成功します。不一致があるまれなケースでは、はい、共有オブジェクトライブラリの2つ以上のコピーをメモリに置くことが必要になる場合があります。

明らかに、プログラムやプログラムインスタンス間でライブラリのロードアドレスをランダム化しようとすると（悪用可能なパターンが作成される可能性を減らすため）、そのようなケースが一般的であり、まれではないため、システムがこの機能を有効にしている場合、すべての共有オブジェクトライブラリをコンパイルして、位置に依存しないようにする必要があります。

メインプログラムの本体からこれらのライブラリへの呼び出しも再配置可能になるため、共有ライブラリをコピーする必要がほとんどなくなります。