ターゲットでを使用してu-boot-2011.12
いOMAP3
ます。クロス ツール チェーンは ですCodeSourcery arm-none-linux-gnueabi
。コンパイルu-boot
し、ターゲットにダウンロードして起動しました。すべてうまくいきましたが、u-boot
再配置機能についていくつか質問があります。この機能がPIC
(位置に基づいていることはわかっています)独立コード)、-fpic
フラグをに設定することで位置独立コードが生成されますが、コンパイル フラグがgcc
見つかりません。fpic
PIC がなければ、u-boot はどのように再配置機能を実装できますか?
2 に答える
u-bootが実行されているときは、まだOSがないことを覚えておいてください。ほとんどのユーザーアプリケーションで使用されている「pic」機能は実際には必要ありません。以下で説明するのは、PowerPCアーキテクチャーです。
u-bootは、最初はNVメモリ(NANDまたはNOR)で実行されています。u-bootは、ほとんどの周辺機器(特にRAM)を初期化した後、RAMの最上位を特定し、グローバルデータ用に一部の領域を予約してから、RAMにコピーします。次に、u-bootはRAM内のコードに分岐し、修正プログラムを変更します。u-bootがRAMに再配置されました。
アーキテクチャのstart.Sファイルを見て、relocate_code()関数を見つけます。次に、勉強、勉強、勉強...
私もこれが厄介だと思い、この質問について数時間頭を悩ませました。
幸運なことに、u-boot メーリング リストで次のスレッドを見つけました。
http://lists.denx.de/pipermail/u-boot/2010-October/078297.html
つまり、少なくとも ARM では、COMPILE TIME で -fPIC/-fPIE を使用して、位置に依存しないバイナリを生成する必要はありません。できる限り多くの作業を事前に行うことで、ランタイム ローダーのタスクを軽減しますが、それだけです。
fPIC を使用するかどうかに関係なく、LINK TIME で常に -pic / -pie を使用できます。これにより、位置に依存するすべての参照が再配置セクションに移動します。COMPILE TIME でヘルパーを追加する処理が実行されていないため、このセクションは -fPIC を使用する場合よりも大きくなることが予想されます。
彼らは、目的のために -fPIC を使用しても、リンク時のみのソリューションよりも大きな利点はないと結論付けています。
[編集] 参照用に commit u-boot 92d5ecba を参照してください
arm: ELF 再配置を実装 http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=92d5ecba47feb9961c3b7525e947866c5f0d2de5