プログラムロードのためのセグメント作成について

[TOKIKO OTA]

いつもお世話になっています。

 

リンカスクリプトでMEMORYコマンドによって指定する領域とELFヘッダ、プログラム・ヘッダ・テーブル

の関係について、さらに、セグメントの生成についての質問です。

 

6thステップ、p213、13行目辺りに

“ram領域は内蔵RAMの先頭であるアドレス0xffbf20ではなく、0xffc020として定義しています。

これはELFヘッダとプログラム・ヘッダ・テーブルもメモリ上にロードされるようにセグメント作成されるため、

先頭に空きを作っているためです。”

とあります。

 

ヘッダがあるので、リンカスクリプトで定義したram領域の上に256バイトの空きを作ることは納得したのですが、

この空いたところにELFヘッダとプログラム・ヘッダ・テーブルが配置されるようにセグメントが生成されるという

理解でよろしいですか？

 

だとすると、このようにセグメントを生成するのはELFファイルを生成するコンパイラがやってくれているのでしょうか？

 

7thステップ、p268、リスト7.9でソフトウェア割込みベクタの領域をRAMの先頭に追加していますが、上述の空き領域

と被っていても、コンパイラがうまくセグメントを生成してくれるから大丈夫なのかな、と思いました。

 

 

コンパイラがうまくセグメントを生成してくれていると思ったその他の理由として、6thステップp217のreadelfをしたときの

プログラムヘッダーで、一つ目のセグメントの物理アドレスが、0x00ffbfacとなっていて微妙にRAMの先頭アドレス(0x00ffbf20)になって

いないのも何か都合がいいように調整が入ったからかなと考えたからです。

 

変な質問でしたらすみません。よろしくお願いいたします。

[SAKAI Hiroaki]

坂井です．

>> 6thステップ、p213、13行目辺りに
>> “ram領域は内蔵RAMの先頭であるアドレス0xffbf20ではなく、0xffc020として定義しています。
>> これはELFヘッダとプログラム・ヘッダ・テーブルもメモリ上にロードされるようにセグメント作成されるため、
>> 先頭に空きを作っているためです。”
>> とあります。
>>
>> ヘッダがあるので、リンカスクリプトで定義したram領域の上に256バイトの空きを作ることは納得したのですが、
>> この空いたところにELFヘッダとプログラム・ヘッダ・テーブルが配置されるようにセグメントが生成されるという
>> 理解でよろしいですか？

はい，そうです．

>> だとすると、このようにセグメントを生成するのはELFファイルを生成するコンパイラがやってくれているのでしょうか？

実際にはリンカが行うことになります．

>> 7thステップ、p268、リスト7.9でソフトウェア割込みベクタの領域をRAMの先頭に追加していますが、上述の空き領域
>> と被っていても、コンパイラがうまくセグメントを生成してくれるから大丈夫なのかな、と思いました。

実際には 0xffbf20～ の先頭付近のみがソフトウェア割込みベクタとして
利用されます．また前述のELFヘッダは 0xffc020 から数十バイト前の位置
(p.217のreadelfの結果では，0xffbfacになっています)になります．

このため実際にはぶつからない，ということになっています．

>> コンパイラがうまくセグメントを生成してくれていると思ったその他の理由として、6thステップp217のreadelfをしたときの
>> プログラムヘッダーで、一つ目のセグメントの物理アドレスが、0x00ffbfacとなっていて微妙にRAMの先頭アドレス(0x00ffbf20)になって
>> いないのも何か都合がいいように調整が入ったからかなと考えたからです。

これは，コンパイラ(正確にはリンカ)がうまくそのように生成してくれていると
いうよりは，リンカが生成する実行ファイルがそのようなアドレス配置になるので，
それに合わせて(ぶつからないように)ソフトウェア割込みベクタのアドレスを
調整して決めています．

「0x00ffbfac」というアドレスは，テキスト領域の先頭(0xffc020)からELFヘッダを
その前に追加して逆算することで，このようなアドレスになっているようです．
つまり 0xffc020 - 0xffbfac = 116バイトが，ELFヘッダ＋プログラムヘッダとして
消費されているということになります．

[TOKIKO OTA]

ありがとうございました。よくわかりました。