Linker && Loader
■ このスレッドは過去ログ倉庫に格納されています
0001さとし ◆k4PcAe16
NGNG難しいような気がするんですが。。。
僕もリンカとローダを作れるようになれますか？
0082デフォルトの名無しさん
NGNG質問混じりのレスと煽りを一緒にするとは
0083山崎渉
NGNGﾋﾟｭ.ｰ ( ＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎――◎ 山崎渉
0084デフォルトの名無しさん
NGNG0085デフォルトの名無しさん
NGNGいまのところこいつを詳しく知らないとプログラミングに困る状況がないんですが。
本に書いてある内容も、新しい言語では殆ど自動化されて
メモリ節約以外ではそんなに意識する必要瀬がないんではないかと。
0086デフォルトの名無しさん
NGNGふつーにアプリケーション作るなら、
こんな本読む必要はないでしょう。
雑学として覚えておいて損はないと思うけどね。
0087デフォルトの名無しさん
NGNGこんなことしりたがってる香具師は新しい言語でも作る気か？
いまから新しい言語をつくるよりも既存の言語用にフレームワークを開発しているほうが
ましだろ。
0088デフォルトの名無しさん
NGNG必須の知識だと思うが。
新しい言語だろうがそうでなかろうがな。
例えば、ActiveBasicの作者はこういう知識をもってるだろうし、
もっと華やかな所で言えば、gccやJavaなんかの開発チームは
こういう知識が必要だろ。
0089デフォルトの名無しさん
NGNG結局コンパイラを作りたいんじゃないかい。
作らない香具師には知識が増えるだけで関係ないって凝った。
0090デフォルトの名無しさん
NGNG0091デフォルトの名無しさん
NGNGOSつくるよりもその上で動くアプリケーション作ったほうが効率がよろし
0092デフォルトの名無しさん
NGNGなぜかELFなsoをwindowsで使わないといけない状況では、必要な知識でしょう。
そんな状況に直面する事は滅多に無いと思うが。
0093デフォルトの名無しさん
NGNGある人には関係あって、ある人には関係ない。
自分に関係ないからって、他人に文句言うのは筋違いだろ。
コンパイラ作るのが有意義な人だっているんだよ。
0094デフォルトの名無しさん
NGNG0095デフォルトの名無しさん
NGNGhttp://www.skyfree.org/linux/references/ELF_Format.pdf
これだけ？
それからELFの表現し得るすべてをldやそのリンカスクリプトで表現できるの？
（できないものを現したいときは、バイナリエディタか？ｗ）
どっちにしてもELFのフォーマルな仕様書が仮にあったとしても、
その主な実装系たるGNUツールが対応してなければ、意味がないということか。。。
0096_
NGNG0097名無し＠沢村
NGNGリンカをつくるのは、OMFやHEXのフォーマットを知っていれば充分だよ。
OMFはHEXのフォーマットは前はインテルのサイトからDLできたけど、いまはできないようだよ。
あと、ローダはWindowsが勝手にやってくれるから、つくる必要はないよ。
0098デフォルトの名無しさん
NGNG0099デフォルトの名無しさん
NGNGそれに対する、カーネルモジュールからローダー、リンカ、アセンブラ
なんかのツールを作ればかなり勉強になりそうだ。
誰かやったことある人いる？
0100デフォルトの名無しさん
NGNG0101デフォルトの名無しさん
NGNG0102デフォルトの名無しさん
NGNG0103デフォルトの名無しさん
NGNGリンカの知識が必要なのはコード生成部なので、
なぜJavaCCと特定しているのかわからん。
0104デフォルトの名無しさん
NGNGJVM の内部に手を突っ込みたいなら必要。
0105デフォルトの名無しさん
NGNG0106_
NGNG0107名無し＠沢村
NGNGアプリケーションプログラマーなんて、ツクールでＲＰＧをつくってるやつと一緒でエンジニアとは言えないな。
ツクールそのものをつくるのがエンジニア。
0108デフォルトの名無しさん
NGNG今揉めてるSCOだけど、ELF、というかもう少し広く考えて
UNIXのABI全般に関しては一応ここかと
http://www.caldera.com/developers/devspecs/
0109デフォルトの名無しさん
NGNGツクールもアプリケーションだと思うけど･･･
0110デフォルトの名無しさん
NGNGお前は一生機械語だけでコーディングしてろ！
0111デフォルトの名無しさん
NGNG0112デフォルトの名無しさん
NGNGだれかあぼぼぼ
0113山崎 渉
NGNG__∧＿∧_
|（ ＾＾ ）| ＜寝るぽ（＾＾）
|＼⌒⌒⌒＼
＼ |⌒⌒⌒~| 山崎渉
~￣￣￣￣
0114デフォルトの名無しさん
NGNG0115山崎 渉
NGNG0116山崎 渉
NGNG│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
0117デフォルトの名無しさん
NGNG0118デフォルトの名無しさん
NGNGだろうな。
ひげぽんにおせーてやれ。
藻前の作ってるＯＳにﾛｰﾀﾞはいらねぇとな。
0119デフォルトの名無しさん
NGNGローダーっつー概念がなかったな。
（その後のバージョンはしらん）
つまりファイルイメージ=メモリイメージ だ。
完全リロケータブルなバイナリコードを前提として
ディスクからメモリに読み込むだけで
アドレスの解決は一切しない。
PC相対アドレッシングが強力な6809だからできたんだろうけど
（同じ命令でもPC相対のほうが早かったりした
80系でそんなことしたらえらい非効率だったろう。）
あと、ファイルイメージをそのままROMに焼けたりした。
起動プロセスがメモリマップをチェックして
マジックナンバーを見つけると
勝手にモジュールを認識してくれたりした。
0120デフォルトの名無しさん
NGNGC言語にはとってもとっても難しくって出来ない事が、
簡単に出来ちゃうから面白いよ。
外部結合の識別子を日本語に直してみたりね。
0121デフォルトの名無しさん
NGNG0122デフォルトの名無しさん
NGNG・ケーブル：Flash2Advance USB Linker
・ソフト：Flash2Advance Writer 3.1 Win9x/Me/NT/2000/XP (28-07-2003)
の組み合わせで手持ちのGBAのロムを吸い出そうと
しているんですがstartとserectを押しながら電源をonすると
Flash2Advance Writer 3.1がフリーズしてしまいます。
また本体側も認識した時特有の画面になりません。
デバイスマネージャーでUSBのドライバは認識しているよう
なんですが。
どのような不具合が考えられますでしょうか？
初心者の質問ですいません。
よろしくお願いいたします。
0123デフォルトの名無しさん
NGNG0124デフォルトの名無しさん
NGNGあなたの脳味噌が不正な処理を行っています。
最新の物を再インストールして下さい。
0125デフォルトの名無しさん
NGNG見たら、テストコードがぐちゃぐちゃに入ってて萎えた
0126デフォルトの名無しさん
NGNG間違ってるかもしれんけどｗ
0127デフォルトの名無しさん
NGNG>>613
>関連ドキュメントが少なすぎるぅぅぅ（泣
MINIXの本とか読んでみたら?
タンネンバウムのOSの本とかさ。
昔のbitには良くこんな記事があったんだが。
(図書館でバックナンバーを読んだ)
0128592 ◆m/EAH1Sb4Q
NGNG自分は今、「Loaderとはなんぞや？Linkerとはいったい全体なんなんだ？」って考えで
↓の本を読みながら学んでいるところです。
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=4-274-06437-9
オーバーレイの章を読んでいまいちピンとこないのでモヤモヤがあります。
ある方によると、
>オーバーレイを有効に使うためには、プログラムを同じタイミングで呼ばれる
>可能性がある複数の部分に *手作業で* 分割し、さらに読み込みタイミングを
>自分で制御する必要がある。
だそうですが、いまいちピンときません。
この部分は誰が（どこが）その処理を担当をするのか？
現在は、オーバーレイだけに時間をかけるわけに行かないので次に進んでます。
共有ライブラリの章に突入している途中ですが、今までCやC++でコーディングしてきたけど、
こんなことちっとも知らなかった。すばらしい、感動しました。（まだ読み終わってなく途中ですけど笑）
>>127
>MINIXの本とか読んでみたら?
>タンネンバウムのOSの本とかさ。
実はもう中古で買って読んじゃいました。でもLinkerやLoader関連なんてなかったような．．．
↓
MINIXオペレーティングシステム
>昔のbitには良くこんな記事があったんだが。
>(図書館でバックナンバーを読んだ)
むむっ！！見たい！知りたい！どこにあります？
0129592 ◆m/EAH1Sb4Q
NGNGあれ？
やっぱ誰も見てないんじゃないだろうか？＞このスレ
鬱だ。
0130デフォルトの名無しさん
NGNGここのVROOMMというのは違うのかな？
0131デフォルトの名無しさん
NGNGloaderなかったら、program実行できないじゃない。
0132デフォルトの名無しさん
NGNG> GCCスレから誘導されてきました。
(略)
> この部分は誰が（どこが）その処理を担当をするのか？
人がやるかソフトウェアがやるかは環境によるよね。
オーバーレイだから、組み込み系の人に聞くんがいいんじゃない?
GCCスレに書いたけど、それやるアセンブラ、リンカ使ったことあるよ。
大型で動いていたHLISPってLispの処理系も自分でやってたね。
アドレス空間が狭かったからね。
0133デフォルトの名無しさん
NGNG共立出版の雑誌"bit"は、
大学の図書館(工学系)行けば必ずある。
0134デフォルトの名無しさん
NGNG良い奴等はみんな氏んじまった。
0135デフォルトの名無しさん
NGNG文系PGにはTransTechみたいな雑誌が丁度いいかと
思えたけど、あれも直ぐ潰れちゃったよね。
結局コボラー相手の雑誌しか生きのこれないということか。
0136592 ◆m/EAH1Sb4Q
NGNG>>130
>ttp://www.borland.co.jp/bcsuite/tc40j.html
>ここのVROOMMというのは違うのかな？
そうかもしれませんが、どうやってるのか知ることができません。Borlandの独自技術かな？
>>131
>loaderなかったら、program実行できないじゃない。
それはそうですけど、loaderやlinkerに関しての理論や説明が無いってことでした。
>>132
>人がやるかソフトウェアがやるかは環境によるよね。
>オーバーレイだから、組み込み系の人に聞くんがいいんじゃない?
>GCCスレに書いたけど、それやるアセンブラ、リンカ使ったことあるよ。
>大型で動いていたHLISPってLispの処理系も自分でやってたね。
>アドレス空間が狭かったからね。
なるほど、ありがとうございます。
うーむ、どうも最近それほどオーバーレイにこだわる必要はないんじゃないかって気がしてきました。
使用範囲が限られてるようだし．．だから次の章に進んでます。
>>133
>共立出版の雑誌"bit"は、
>大学の図書館(工学系)行けば必ずある。
学生ではないんですが、一般の人でも入れるんですか？
0137デフォルトの名無しさん
NGNGゼロから全てのソフトを書き上げる能力を、皆が持っていた
時代から比べれば、今のPGはアホウの集まりのようだ。
原始人て、もの凄く頭悪そうなイメージがあるけど、実はかなり
賢い生き物だったのかもしれないね。生きるための創意工夫を
独自に発案できない椰子は生きていけない世界だったのかもしれない。
0138592 ◆m/EAH1Sb4Q
NGNG>文明が発達すると、人の能力も落ちてくるんじゃないのかな。
>ゼロから全てのソフトを書き上げる能力を、皆が持っていた
>時代から比べれば、今のPGはアホウの集まりのようだ。
>原始人て、もの凄く頭悪そうなイメージがあるけど、実はかなり
>賢い生き物だったのかもしれないね。生きるための創意工夫を
>独自に発案できない椰子は生きていけない世界だったのかもしれない。
そうですね。
人間って弱い生き物なので、一度うまくやってしまうとだんだんと楽をしようとしてしまって、
楽な方へ楽な方へと流されてしまう。
そして気づいたらそれをどうやってすればいいのか、どうなっているのかすらわからなくなってしまっている。
こういうことが最近多くなってきているような気がします。＞我も
0139デフォルトの名無しさん
NGNGFORTRANのCOMMONは知っていますか?
これが現在最大派閥のオーバーレイじゃないかな。
それから大学の図書館で外部の人を入れないところなんてほとんどないよ。
大学の目的に反しているからね。身分証明書があればほとんどOK。
貸し出しはしてくれなくても有料コピーサービスは受けられる。
OPACで在庫図書を検索できるし。
気をつけるのは、学科の図書室は入れないことが多いこと。
0140592 ◆m/EAH1Sb4Q
NGNG>FORTRANのCOMMONは知っていますか?
>これが現在最大派閥のオーバーレイじゃないかな。
残念ながら、自分はFORTRANは使用したことがありません。
>それから大学の図書館で外部の人を入れないところなんてほとんどないよ。
>大学の目的に反しているからね。身分証明書があればほとんどOK。
>貸し出しはしてくれなくても有料コピーサービスは受けられる。
>OPACで在庫図書を検索できるし。
>気をつけるのは、学科の図書室は入れないことが多いこと。
わざわざ、知らせてくれてすいません。
そこ大学の学生でなければ見れないと思ってました。
後で気づいたんですけど国会図書館を使うっていう手段もあるなと思いました。
現在は、１０章「動的なリンクとロード」を読み終えて、１１章へ突入。
１０章は、中々面白かったです。一番身近な感覚で勉強できますからね。
今日中に終わるか！？
0141592 ◆m/EAH1Sb4Q
NGNG最後は、Javaでした。ちょこっとしかなかったけど無いよりましか。
全てをざっと読んだ感想は、やはり一筋縄にはいかないものだと思った。
Linker、Loaderを詳細に分かりたい人はこの本だけでなく、
その他の書籍、Web、ソース参照等でカバーしなくてはいけないと思う。
自分もこれからいろいろと調べなくてはならないことが山程あるなと感じた。
0142デフォルトの名無しさん
NGNGをリンクする事は出来ないのでしょうか？
新規作成分のa.o b.o c.o と既存の流用可能な hoge.a があった
時に、a.o, b.o, c.o, hoge.a から libHoge.so を作りたいのですが、
どうしても hoge.a をリンクしても libHoge.soにシンボルがリンク
されません。
0143デフォルトの名無しさん
NGNG*.aはそうなっていないので、*.soに取り込むことはできない。
arで*.oにばらしてもダメ。
外部シンボルへの参照方法が根本的に違う。
0144デフォルトの名無しさん
NGNGそれはつまり、再配置可能な形態(EXE,DLL)と
オブジェクトファイルの違いということですか？
*.aというのは用はオブジェクトファイルの集合体ですよね。
オブジェクトファイル内のアドレス値は、ファイルイメージ内の
相対アドレスすら決定されていない(リンク時にそれは決定される)から。
逆に(EXE,DLL)は、ローダによって実行時に、各セクションごとメモリ上に
割り当てられるとしても、それはオブジェクトファイル形式にのっとった
操作だから、先頭から何バイト目かは分る。つまり相対アドレスが
決定できる。EXEはプロセス中に一つしか有り得ないから、
DLLとはまた少し事情が違うのかな。
0145デフォルトの名無しさん
NGNGLinux って *.a から *.so つくるよね？
ld -shared --whole-archive とかって．．．
0146デフォルトの名無しさん
NGNGgccの-fpicを調べてください。
>>143の最後の一行の意味がわかるかと。
0147145
NGNGんー、私が知りたいのは
>143 で
「*.aはそうなっていないので、*.soに取り込むことはできない。arで*.oにばらしてもダメ。」
って言ってるけど、-fpic とか -fPIC でコンパイルしててもダメ(ar で *.o にバラしてもダメ)なの？
なんか -fpic とか -fPIC つきでコンパイルしてたら、ar で *.o にバラしてそれから *.so に取り込めそうだけど．．．
0148デフォルトの名無しさん
NGNGただ、普通は.aだけ作る場合に-fpic付けることはまず無い。
0150デフォルトの名無しさん
NGNG0151デフォルトの名無しさん
NGNG0153デフォルトの名無しさん
NGNG0154デフォルトの名無しさん
NGNG-lhoge とやった際、そのパスに、libhoge.a と libhoge.so の両方が
あった場合、どちらがリンクされるんでしょうか？
またlibhoge.aがリンクされる場合は、静的ライブラリの動的リンクって
事になるんでしょうか？
0156デフォルトの名無しさん
NGNGコードがPICでなくともTEXTRELを処理すれば普通に動きそうだけど。
0157デフォルトの名無しさん
NGNG0158デフォルトの名無しさん
NGNG0159デフォルトの名無しさん
NGNGディスパッチテーブル。
0160デフォルトの名無しさん
NGNG書き換えたらプロセス間で共有出来なくなるが。
そういやWinのDLLって再配置できるけど、あれってメモリ上では共有されないの？
0161デフォルトの名無しさん
NGNG0162デフォルトの名無しさん
NGNGエクスポートする関数やグローバル変数なんじゃなくて、
モジュール内で参照してる、外部シンボルのことなんだよね？
実際、-fPICや-sharedつけても、外部シンボルを一切参照しない
コードなら、readelf -a foo.oの結果が全く同じだし。
0163デフォルトの名無しさん
NGNG内部のみ有効なシンボルであっても絶対番地参照してはならない。
そうして初めて外部シンボルだけ問題なモジュールとなる。
0164デフォルトの名無しさん
NGNGオオボケかましてました。自動変数だけのプログラム書いてました（汗
モジュールローカルなstatic変数とそれを用いるプログラム（宣言だけでは
もちろんダメ）を書いたら、-fPICの有無で、ちゃんとreadelf -aにおいて
異なる結果が得られました。何が違うのかはこれからよく見てみますが。
0165164
NGNGstatic int abc=2;
int foo(void){int i=abc;}
$gcc -c foo.c;readelf -a foo.o > nopic.txt;gcc -c foo.c -fPIC;readelf -a foo.o > pic.txt
$diff nopic.txt pic.txt
いろいろあるけどとりあえず、セクションごとのサイズに注目すると、
< [ 1] .text PROGBITS 00000000 000034 000010 00 AX 0 0 4
< [ 2] .rel.text REL 00000000 0002b0 000008 08 7 1 4
< [ 7] .symtab SYMTAB 00000000 000200 000090 10 8 8 4
< [ 8] .strtab STRTAB 00000000 000290 00001e 00 0 0 1
----
> [ 1] .text PROGBITS 00000000 000034 000024 00 AX 0 0 4
> [ 2] .rel.text REL 00000000 0002e8 000010 08 7 1 4
> [ 7] .symtab SYMTAB 00000000 000214 0000a0 10 8 8 4
> [ 8] .strtab STRTAB 00000000 0002b4 000034 00 0 0 1
この辺りかな。
・.rel.textのエントリが1 -> 2、.symtabが9 -> 10になってる。
・エントリのサイズは.rel.textが8バイト、.symtab16バイト。
・それぞれ、_GLOBAL_OFFSET_TABLE_という名前のエントリが増えてる。
ってな感じですかね。
0166デフォルトの名無しさん
NGNG> 書き換えたらプロセス間で共有出来なくなるが。
勿論そうだけど、動くには動くでしょ。
PICでない*.aを*.soに取り込めないのは不思議。
>>165
shared objectは利用するプロセス毎に違うアドレスへ配置され得る。
だからコード中で直接絶対番地指定するとその部分を再配置しない限り
正常に動作してくれない。
で、再配置(=ここでは読み取り専用領域の書き換え)をしてしまうと>>160にある通り
メモリの共有が出来なくなって、プロセス毎にコピーを持つ必要が出来る。
PICなコードでは絶対番地指定が必要な時に
Global Offset Table(GOT)を通して間接的にアクセスする。
これだと読み取り専用領域を書き換える必要が無くなるので、
異なるプロセス間でその領域を共有出来るようになる。
i386ではGOTの参照に_GLOBAL_OFFSET_TABLE_という名前を使う事が出来る。
因みにdynamic linkerを通して関数を呼び出す時は
Procedure Linkage Table(PLT)ってのが使われる。
i386ではPLTはGOTを参照する変則的なジャンプテーブル。
link editorは外部関数等の呼び出しをPLTの該当エントリの呼び出しに
置き換え、実行時にPLTのコードはGOTを通してdynamic linkerの
シンボル解決ルーチンへジャンプする。
0167デフォルトの名無しさん
NGNG１．GOT経由で２．へジャンプするコード
２．dynamic linkerへジャンプするコード
に分かれている。
dynamic linkerは２．から処理を受け取った時に１．で参照した
GOTのエントリを与えられるので、それを書き換える事により
2度目以降の同じ関数の呼び出しはdynamic linkerを通さずに
１．から直接ジャンプする事が出来る。
0168デフォルトの名無しさん
NGNG>PICでない*.aを*.soに取り込めないのは不思議。
これは、オブジェクトファイルのTYPE=PROGBITSの
.textと.dataセクション、TYPE=RELの.rel.textや.rel.dataを
ちょこっと書き換えればPIC形式のオブジェクトファイルに
変換できるだろう、という意味ですか？
0169デフォルトの名無しさん
NGNG変換しない。
PICがPosition Independent Codeの略なのはオッケー？
コードをPICにする必要があるのは読み取り専用の領域を
プロセス間で使い回す為に再配置を避けたいから。
非PICな(直接絶対番地指定する)コードであっても、
dynamic linkerが読み取り専用領域を一旦書き込み可能にして再配置すれば
プロセス間でメモリ領域の共有が出来ないだけで動作はする筈。
「セクション」って事はlink editorの仕事について言ってるんだろうけど、
link editorはコードが読み取り専用領域のデータの再配置を必要とする場合に
DT_TEXTRELなりDF_TEXTRELなりの情報を載せてdynamic linkerが
正しく処理出来るようにすれば良いんじゃないかな。
0170デフォルトの名無しさん
NGNG>変換しない。
そうはいっても>>165の簡単なCのコードですら、アセンブラにした段階で
.textセクションに異なるコードを生成してますよ。
NON-PIC
foo:
subl $4, %esp
movl abc, %eax
movl %eax, (%esp)
addl $4, %esp
ret
.size foo, .-foo
PIC
foo:
subl $4, %esp
call __i686.get_pc_thunk.cx
addl $_GLOBAL_OFFSET_TABLE_, %ecx
movl abc@GOTOFF(%ecx), %eax
movl %eax, (%esp)
addl $4, %esp
ret
.size foo, .-foo
.section .gnu.linkonce.t.__i686.get_pc_thunk.cx,"ax",@progbits
.globl __i686.get_pc_thunk.cx
.hidden __i686.get_pc_thunk.cx
.type __i686.get_pc_thunk.cx, @function
__i686.get_pc_thunk.cx:
movl (%esp), %ecx
ret
0171デフォルトの名無しさん
NGNGそれで何が問題だと思うの？
0172デフォルトの名無しさん
NGNGアセンブラソースをはりましたが、PICは>>167に書かれている通り、
GOT経由でモジュールローカルな変数(ここではabc)にアクセスしてますよね。
もし仮にNON-PICなモジュールをPICなモジュールとして使おうとすれば、
そのようなGOTへのアクセスルーチンを埋め込み、.rel.textセクションにGOTの
エントリを追加しなくてはならないように思います。
0173デフォルトの名無しさん
NGNG非PICなコードに必要なのは
movl abc, %eax
のabcの再配置であって、GOT経由のアクセスにする事ではないんじゃ。
0174デフォルトの名無しさん
NGNG>非PICなコードに必要なのは
>のabcの再配置であって
非PICコードからEXEを作るなら、static変数の
アドレスはリンク時に確定すると思うけど。
.rel.textセクションにエントリが追加されてるのは、
リンク時に.textセクション内のアドレス解決を行うものの
一覧だと思うし。
0175デフォルトの名無しさん
NGNGEXEではそう。
0176デフォルトの名無しさん
NGNG>>174
実行するアドレスが一意に決まるなら、それでも問題はないですな。
つーかstaticに限らず全てのアドレス参照がリンク時に解決できなきゃいけない。
あと.rel.textはアドレス解決には関係ない。
例外としてDOSみたいに実行時にアドレスが決定される場合は、ロードした時に
ごにょごにょやるしか無いけど。
今時そんなOSはまずないが。
0177デフォルトの名無しさん
NGNG.rel.textセクションというのは、.textセクション内の
コード中における、アドレス値の一覧なのではないでしょうか。
各エントリは.textセクション内のオフセットを示していると思いますがいかがでしょうか。
下は>>167のコードを-fPICをつけてコンパイルしたものの.rel.textセクションです。
Relocation section '.rel.text' at offset 0x3c8 contains 3 entries:
Offset Info Type Sym.Value Sym. Name
00000004 00000a02 R_386_PC32 00000000 __i686.get_pc_thunk.cx
0000000a 00000b0a R_386_GOTPC 00000000 _GLOBAL_OFFSET_TABLE_
00000010 00000309 R_386_GOTOFF 00000000 .data
↑ここのOffsetとは.textセクションの先頭からのバイト数だと思います。
.rel.textを含む、TYPE=RELであるセクションに登録されている各エントリのデータ構造
/* Relocation table entry without addend (in section of type SHT_REL). */
typedef struct
{
Elf32_Addr r_offset; /* Address */
Elf32_Word r_info; /* Relocation type and symbol index */
} Elf32_Rel;
/* i386 relocs. */ 各エントリのタイプ一覧の抜粋 Elf32_Rel.r_infoの値
#define R_386_PC32 2 /* PC relative 32 bit */
#define R_386_GOTOFF 9 /* 32 bit offset to GOT */
#define R_386_GOTPC 10 /* 32 bit PC relative offset to GOT */
コードはLINUX GLIBC-2.3.3のelf.hを参考にしました。他のOSだと型名などが
微妙に違うと思います。
0178デフォルトの名無しさん
NGNG00000000 <foo>:
0:83 ec 04 sub $0x4,%esp
3:e8 (fc ff ff ff) call 4 <foo+0x4> ;;__i686.get_pc_thunk.cx
8:81 c1 (02 00 00 00) add $0x2,%exc ;;_GLOBAL_OFFSET_TABLE_
e:8b 81 (00 00 00 00) mov 0x0(%ecx),%eax ;;.data
14:89 04 24 mov %eax,(%esp,1)
17:83 c4 04 add $0x4,%esp
1a:c3 ret
00000000 <__i686.get_pc_thunk.cx>:
0:8b 0c 24 mov (%esp,1),%ecx
3:c3 ret
$gcc -fPIC -shared -fomit-frame-pointer -o foo.so foo.c
$objdump -d foo.so から抜粋
00000648 <foo>:
648: 83 ec 04 sub $0x4,%esp
64b: e8 (13 00 00 00) call 663 <__i686.get_pc_thunk.cx>
650: 81 c1 (50 11 00 00) add $0x1150,%ecx ;;GOTのアドレスを%ecxに設定
656: 8b 81 (28 ff ff ff) mov 0xffffff28(%ecx),%eax ;;%eaxにabcの値をコピー
65c: 89 04 24 mov %eax,(%esp,1)
65f: 83 c4 04 add $0x4,%esp
662: c3 ret
00000663 <__i686.get_pc_thunk.cx>:
663: 8b 0c 24 mov (%esp,1),%ecx
666: c3 ret
0179デフォルトの名無しさん
NGNG型名とマクロはELFの本家ドキュメントのと同じで、
i386なら*BSDでも同じ名前を使ってます。
これ以上何と説明すれば良いやら分からないので、
ゼヒとも仕様を読んでくらはい……。
ELFにはrelocatableとexecutable、sharedの三形式があり、
再配置はlink editorとdynamic linkerの両方が扱うもので
それぞれの意味が違うってのは大丈夫ですよね？
>>169に書いた通り、>>173の再配置というのは
dynamic linkerが行う再配置の事を言っています。
0180デフォルトの名無しさん
NGNG>型名とマクロはELFの本家ドキュメントのと同じで、
>i386なら*BSDでも同じ名前を使ってます。
そうでしょうか。私はNetBSDとLinuxを使っていますが、
Elf32_Symに関しては、NetBSDは本家のドキュメントと異なっているように見えます。
ざっと見た印象により、上には書いただけですし、
ちょこっと調べた結果判明したのはここだけだったのでなんとも言えませんが。
CVS-HEAD
/usr/src/sys/sys/exec_elf.h
typedef struct {
Elf32_Wordst_name;/* Symbol name (.symtab index) */
Elf32_Wordst_value;/* value of symbol */
Elf32_Wordst_size;/* size of symbol */
Elf_Bytest_info;/* type / binding attrs */
Elf_Bytest_other;/* unused */
Elf32_Halfst_shndx;/* section index of symbol */
} Elf32_Sym;
GLIBC-2.3.3はこうです。
typedef struct
{
Elf32_Wordst_name;/* Symbol name (string tbl index) */
Elf32_Addrst_value;/* Symbol value */
Elf32_Wordst_size;/* Symbol size */
unsigned charst_info;/* Symbol type and binding */
unsigned charst_other;/* Symbol visibility */
Elf32_Sectionst_shndx;/* Section index */
} Elf32_Sym;
0181デフォルトの名無しさん
NGNGCVS-HEAD
/usr/src/sys/sys/exec_elf.h
typedef struct {
Elf32_Word st_name; /* Symbol name (.symtab index) */
Elf32_Word st_value; /* value of symbol */
Elf32_Word st_size; /* size of symbol */
Elf_Byte st_info; /* type / binding attrs */
Elf_Byte st_other; /* unused */
Elf32_Half st_shndx; /* section index of symbol */
} Elf32_Sym;
GLIBC-2.3.3
typedef struct
{
Elf32_Word st_name; /* Symbol name (string tbl index) */
Elf32_Addr st_value; /* Symbol value */
Elf32_Word st_size; /* Symbol size */
unsigned char st_info; /* Symbol type and binding */
unsigned char st_other; /* Symbol visibility */
Elf32_Section st_shndx; /* Section index */
} Elf32_Sym;
あと
>再配置はlink editorとdynamic linkerの両方が扱うもので
>それぞれの意味が違うってのは大丈夫ですよね？
それはいいのですが、
>あと.rel.textはアドレス解決には関係ない。
リンク時において、.rel.textの情報を元に.textセクションのアドレス値を
決定してるように見えますが、これは「アドレス解決」とは呼ばないんですか？
リンク時にGOTへのオフセットを計算してますけど。
■ このスレッドは過去ログ倉庫に格納されています