問題タブ [fpic]

ベアメタルに再配置可能なコードを持つプロジェクトを構築しています。Cortex M3 組み込みアプリケーションです。私はダイナミック リンカを持っておらず、スタートアップ コードにすべての再配置を実装しました。

ほとんどの場合は機能していますが、ローカルの静的変数が正しく配置されていないようです。それらのアドレスは、実行可能ファイルがメモリ内でオフセットされる量だけオフセットされます。つまり、メモリ位置 0 にロードされているかのようにコードをコンパイルしますが、実際には 0x8000 にあるメモリにロードします。静的ローカル変数のメモリ アドレス オフセットは 0x8000 です。これは適切ではありません。

私のグローバル変数はGOTによって適切に配置されていますが、静的ローカル変数はGOTにまったくありません（少なくとも、実行時に表示されませんreadelf -r）。私は自分のコードをコンパイルしており-fpic、リンカは指定されています。静的ローカル変数にGOTを使用する ように指示するか、それらに絶対アドレス指定を使用するように指示するコンパイルおよび/またはリンクオプションが欠落しているに違いないと思います。-fpic-piegcc

現在、コードは静的ローカル変数の場所に PC を追加しているようです。

libhelper.a私は、1 つの静的ライブラリと、実際の共有オブジェクト ライブラリを含む別のプロジェクトを持っていますlibtestlib.so。私の目標は にリンクlibhelper.aすることlibtestlib.soです。Linux/BSDでそれは可能ですか? テストプログラムを作成しようとすると、次のエラーが発生しました。

./prog1:/usr/local/lib/libtestlib.so.1.0: 未定義のシンボル ''

私の推測では、libhelper.a がコンパイルされていなかったために発生していると思われ-fPICますlibtestlib.so。静的ライブラリにも依存する共有ライブラリを使用するプログラムを構築する適切な方法は何ですか?

ありがとう！

位置独立コードは絶対位置ではなく相対位置のみを使用すると言われていますが、これは c とアセンブリでそれぞれどのように実装されていますか?

char test[] = "string";例として、相対アドレスで参照する方法を考えてみましょう。

オブジェクト ファイル (.o ファイル) が PIC 対応かどうかを確認する方法はありますか?

Linux マシンで ImageMagick をクロスコンパイルしようとしています。ツールチェーンに付属する libstdc++.a は、fPIC でコンパイルされていません。代わりにsoファイルを使用したいと思います。ただし、libtool は libstdc++.a を (アーカイブ全体として) リンクし続け、再配置エラーが発生します。他のライブラリでも同じ問題が発生しました。何か案は？

OSX 10.5 の GCC で -fPIC オプションがデフォルトでオンになっているのはなぜですか? 結局のところ、生成されるコードが大きくて遅いのではないでしょうか?

私は最近受け取った：

...共有オブジェクトを作成する場合、「ローカルシンボル」に対するR_X86_64_32の再配置は使用できません。-fPICで再コンパイルします

プログラムを共有ライブラリとしてコンパイルしようとしたときにエラーが発生しました。

現在、これに対する解決策はそれほど難しくありません（-fPICを使用してすべての依存関係を再コンパイルします）が、いくつかの調査の結果、この問題はx86-64プラットフォームでのみ発生することがわかりました。32ビットでも、位置に依存するコードは動的ローダーによって再配置できます。

私が見つけた最良の答えは次のとおりです。

x86は、.textの再配置をサポートしています（これは、位置に依存するコードがある場合に発生します）。このサポートにはコストがかかります。つまり、そのような再配置を含むすべてのページは、共有ライブラリにある場合でも基本的に非共有になり、共有ライブラリの概念そのものが台無しになります。したがって、amd64ではこれを禁止することにしました（さらに、すべての.text再配置のサイズは「word32」であるため、値に32ビット以上が必要な場合は問題が発生します）

しかし、これは十分ではありません。再配置が共有ライブラリの概念を台無しにする場合、なぜそれを32ビットプラットフォームで実行できるのでしょうか。また、64ビットをサポートするためにELF形式に変更を加える必要がある場合、対応するためにすべてのフィールドのサイズが大きくならないのはなぜですか？

これはマイナーな点かもしれませんが、a）問題のコードは科学的なコードであり、パフォーマンスに影響を与える必要がないのは良いことであり、b）この情報は最初の場所！

[編集：'答え'

@awoodlandsの回答はおそらく最良の「文字通りの回答」であり、@servnはいくつかの良い情報を追加しました。

さまざまなタイプの再配置について詳しく調べるための検索で、これと最終的にはx86_64 ABIリファレンス（68ページを参照）を見つけました]

lib.c動的ライブラリ ( ) とメイン実行可能ファイル ( )で構成されるコードを作成しましたmain.c。両方のファイルで、次の名前のグローバル変数を定義しますint global。あまり賢くはありませんが、それは問題ではありません。

動的ライブラリをコンパイルすると、-fPICオプションは必須のようです:

そうでなければ私は得る：

実行可能ファイルをコンパイルすると、そうではありません。

どちらも機能しますが、説明できない動作が異なりますね。:

-fPIC を使用すると、main.c のグローバルと lib.c のグローバルは同じ変数になります。

-fPIC を使用しないと、lib.c のグローバルは main.c のグローバルに関連付けられません。

ソースは次のとおりです。

lib.c

main.c

gcc --バージョン: gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2

uname -a: Linux xxx 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:02:55 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

edit : SUN/sparc および x86/Linux アーキテクチャで、同じ種類の予期しない共有グローバル変数 (-fPIC を使用) を使用してテストされたコード。

Fedoraで-fPICをサポートするGHCをインストールしようとしています。バイナリのtarballにはこれがないように思われるので、ソースtarballを取得しました。

Build.mkで、クイックビルドタイプをに変更しました

残念ながら、コンパイルするとまだldエラーが発生します

したがって、GHC-primはまだ-FPICでコンパイルされていないようです。また、cabalに-fPICでパッケージをビルドして共有するように指示しました。

誰かアイデアはありますか？

編集：dcoutsのおかげで、私はいくつかの進歩を遂げることができました。しかし今、私はlibffiが-fPICでコンパイルされていないと思うところにいます。makefile（.in）を編集しましたが、これまでのところ運がありません。

新しいコマンドは次のとおりです。

ここで、dllmain.cとHs2lib.hsは両方とも-fPICを使用してコンパイルされています。私が得るエラーは次のとおりです。

collect2：ldが1つの終了ステータスを返しました