Linker && Loader
■ このスレッドは過去ログ倉庫に格納されています
0001さとし ◆k4PcAe16
NGNG難しいような気がするんですが。。。
僕もリンカとローダを作れるようになれますか？
0002デフォルトの名無しさん
NGNG￣￣￣￣￣∨￣￣￣ (´´
∧∧ ） (´⌒(´
⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
￣￣ (´⌒(´⌒;;
ｽﾞｻﾞｰｰｰｰｰｯ
0003さとし ◆k4PcAe16
NGNG0004デフォルトの名無しさん
NGNGとりあえずcomからはじめるがよろし。
0005デフォルトの名無しさん
NGNG0006デフォルトの名無しさん
NGNGそれ読み終えてから出直してこい、ボケ
0007デフォルトの名無しさん
NGNG0008デフォルトの名無しさん
NGNGせめてこれぐらいのことはしろよ。
Ohmsha オーム社 Linkers & Loaders
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=4-274-06437-9
Linkers & Loaders レビュー
http://www.linux.or.jp/bookreview/BR56.html
0009デフォルトの名無しさん
NGNG0010デフォルトの名無しさん
NGNG理解のため……とか。
0011デフォルトの名無しさん
NGNGローダ作るためにはリンカ作れるくらいの理解があったほうが良かろう。
0012デフォルトの名無しさん
NGNG0013ｲﾜｿのﾊﾞｶ
NGNG0014実務経験者
NGNGLib不足でﾘﾝｶｴﾗｰになってるのに、必死でｺｰﾄﾞ見直してるの、見てらんない。
0015デフォルトの名無しさん
NGNG0016デフォルトの名無しさん
NGNG0017デフォルトの名無しさん
NGNG●●●●●●●●恒例・「オセロさえ納期内に作れない＝ＯＯ役立たず 」祭り●●●●●●●
http://pc3.2ch.net/test/read.cgi/tech/1032985885/l50
／| | |＿＿＿＿_ΦΦΦΦΦΦΦΦΦΦΦ||ΦΦΦ
| | |￣￣￣ ／| ||
| | | ／ ／|TTTTTT TTTTTTTTTT||TTTTT
| ／＼ | ／|／|／|^^^^^^ |三三| ^^^^^^^^^^^||^^^^^^^
| ／ ／ |／／ ／ ／|
| ／ ／ |＿|／|／|／|／|
| ／ ／ |文|／ ／／ ／
|／ ／. ＿.|￣|／|／|／ Λ＿Λ
／|＼／ ／ ／ |／ ／ （＿＿_）
／| ／ ／ ／ヽ /〔 非OO 〕〕つ
| |￣| | |ヽ／l ｀/二二ヽ
| | |／| |__|／ Λ＿Λ / /（＿）
| |／| |／ （ ´∀｀） （＿） Λ＿Λ
| | |／ ／/ / ^￣］ﾟ （｀ ）
0018デフォルトの名無しさん
NGNG実務経験してるとは思えん発言だ。
0019さとし ◆Mjk4PcAe16
NGNG0020manko_chinko ◆GLc2rpKRNM
NGNGこれぞ漢
0021デフォルトの名無しさん
NGNG> これぞ漢
漢なら、CPU から作れや。
0022デフォルトの名無しさん
NGNG神をめざすなら、物理法則から作れや。
でも無理だからコンピュータ上でやれや。
そして再帰レベル2へ…
0023デフォルトの名無しさん
NGNG最近はFPGAで手軽にCPUも作れますなぁ
>>22
地球シミュレータで手軽につくれますなぁ（これは嘘）
0024デフォルトの名無しさん
NGNG0025デフォルトの名無しさん
NGNG0026デフォルトの名無しさん
NGNG実に中学生っぽい発言（ｗ
0027デフォルトの名無しさん
NGNGC++ だとコードのミスがリンクエラーを誘発する事が有るんだが。
（テンプレートの実体参照と extern "C" に要注意）
0028デフォルトの名無しさん
NGNGLibが無いというエラーに対して、と書いてますがな。
ちゃんと細かい所まで見ないと。
ｱﾝﾀみたいなのが>>14に書いてあるような失敗するんでっせ。
0029デフォルトの名無しさん
NGNG設定ミスを疑う罠。
0030デフォルトの名無しさん
NGNG>>14 は Lib 不足でリンカエラーと書いているので、
Lib が見つからないのとは違うのでは。
ほんとに Lib 不足かどうかはリンカにはわからんので、
足りないシンボルを人間が確認する必要がある。
ライブラリに有るはずのシンボルが見つからないなら、
当然 Lib 不足。
コード中にあるはずのシンボルが見つからないなら、
>>27 の原因も調べる必要がある。
で、14 は原因が Lib 不足とわかっていたようだが、
必死になっているヤツに教えてあげたんだろうか。
0031デフォルトの名無しさん
NGNG003214
NGNG(1)後ろでﾆﾔﾆﾔ笑ってた
(2)Libが無いんじゃないかと小一時間
(3)放置プレー続行
(4)ものすごい勢いでｷｰﾎﾞｰﾄﾞ強奪してオプション修正
(5)悩んでたのは自分ﾃﾞｼﾀ!
0033rubyist@カラアゲうまうま
NGNG0034デフォルトの名無しさん
NGNG0035デフォルトの名無しさん
NGNG0036デフォルトの名無しさん
NGNG0037デフォルトの名無しさん
NGNG0038デフォルトの名無しさん
NGNGニフティの掲示板なんかじゃ、ちょっと口論になっただけで訴えれらたじゃん。
>>8 お前アホじゃん？
↑こーいう発言もこれからは慎重にしないと・・・・。
あ、でも警察じゃないとIP提出しないんだっけか？じゃぁ各種団体には提出しないのかな？無理だと思うぜぇ
0039デフォルトの名無しさん
NGNG基礎英語聞かなくっちゃｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
0040デフォルトの名無しさん
NGNGと20もの多弾プロ串を経由しているので追跡は不可能です。
0041デフォルトの名無しさん
NGNG/ ´_ゝ`） ＩＰ太郎です。
| /
| /| |
// | |
Ｕ .Ｕ
0042デフォルトの名無しさん
NGNG0043デフォルトの名無しさん
NGNG0044デフォルトの名無しさん
NGNGが施行されて以降の話ですよね。
>>40 ま、一部事実誤認があった事は認めますが、趣旨は間違って無いと思いますよ。
判決文を、もう一度よく読んでみることにします。
0045デフォルトの名無しさん
NGNGこの判決文のなかに「内容証明がなんとか」ってのは書いてあるかってことだな
0046デフォルトの名無しさん
NGNGあぁ、びっくりした。W2Kでﾊｲｽﾍﾟｯｸだから切り抜けられたけど。
いやはや・・・98とか使っている人はひらかないほうが無難。
java scriptは便利なんだけどねぇ・・・こういう使い方は(・A ・)ｲｸﾅｲ!
0047デフォルトの名無しさん
NGNG法的な面をクリアーするのはそれほど難しくないと思います。
ただ、それをどうペイさせるかはかなり難しい予感。
管理者のハードルが高くても、参加者のハードルが低ければ問題ないので、
１つや２つくらいは誰かがやってくれるんじゃないかなと淡い期待。
一方で現在のところ、２ちゃん以外の掲示板的コミュニティーは、参加者のハードルを
高くすることで２ちゃんの抱える問題を解消しようとしている点で、限界が見えている。
0048デフォルトの名無しさん
NGNGIP表示せんと書けない掲示板なんていっぱいあるし
アクセス解析で取られまくりだし。むしろ今更何があかんの？て感じ
0049デフォルトの名無しさん
NGNGアホニシを何とかして欲しいよ。
0050デフォルトの名無しさん
NGNG(･∀･)ﾆﾔﾆﾔ
0051デフォルトの名無しさん
NGNG0052デフォルトの名無しさん
NGNG0053デフォルトの名無しさん
NGNGウザとかって、もしかして真剣に聞いてたのか？
正直すまんかった。厨は早く寝てね。
0054デフォルトの名無しさん
NGNG在日のアサピーが自ら２CHにブラクラ貼ったと自白ｗｗｗ
調子に乗ってアタック開始、しっかりログ取られて通報すました。
祭り中です。
0055デフォルトの名無しさん
NGNG10桁トリップの時に、トオルさんとマァヴさんが、話してましたわね、
0056デフォルトの名無しさん
NGNG２ちゃんねるのお勧めな話題と
ネットでの面白い出来事を配送したいと思ってます。。。
===============================読者数： 139038人 発行日：2003/1/10
なにやら、連日メルマガだしてるひろゆきです。
そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。
重くなって落ちたりしてもご愛嬌ってことで。。。
んじゃ！
────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────
0057デフォルトの名無しさん
NGNGメリットがなくなったね。もう来ないよ。ヤフーにもどろ。
0058デフォルトの名無しさん
NGNGですわね。
0059デフォルトの名無しさん
NGNG0060デフォルトの名無しさん
NGNG0061デフォルトの名無しさん
NGNG0062デフォルトの名無しさん
NGNGあ、そそ。それをいいたかったのよ。
つまりね、
ここ、一般の人は見れない板だからいっちゃうけど、
将来的にはすべてＩＰ取るようにしたいし、
もっと商業的な板にしたいと思ってる。
ヤフーに勝ぐらいのつもりでね。
だけど、今そういうスタンスを取ると、人が離れるだけだから、
表面ではＩＰとらないことをウリにして、
人があつまって、収益の見込みが立ったら
犠牲者でも出して、綱紀粛正するつもりなんですよ。
あ、でもこれあくまでオフレコだから、
内緒ですよ。
この板見れる人なんて決まってるんだから、
ばらしても無駄ですう。
0063デフォルトの名無しさん
NGNG0064デフォルトの名無しさん
NGNG0065デフォルトの名無しさん
NGNG馬鹿はしねよ
0066デフォルトの名無しさん
NGNGもしなんかあったとき、対策とってなかったら叩かれ
るのも関係者だし。
0067デフォルトの名無しさん
NGNG0068デフォルトの名無しさん
NGNG0069デフォルトの名無しさん
NGNGドリキャスをネットにつないでる人って全ブラウザの数％を占めていたのか。
0070デフォルトの名無しさん
NGNG0071山崎渉
NGNG0072デフォルトの名無しさん
NGNG0073山崎渉
NGNG0074山崎渉
NGNG0075デフォルトの名無しさん
NGNG0076デフォルトの名無しさん
NGNG保守あげ
0077山崎渉
NGNG0078山崎渉
NGNG（ ＾＾ ）＜ ぬるぽ（＾＾）
0079デフォルトの名無しさん
NGNG0080デフォルトの名無しさん
NGNG概念や理論だけは理解しろといいたいんだろ？
必ずしもこれを覚えなければ何もかも全くできない状況は
減りつつあるし
0081デフォルトの名無しさん
NGNG0082デフォルトの名無しさん
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へのオフセットを計算してますけど。
0182デフォルトの名無しさん
NGNGそう言えばElf_Byteとかやってたな……。
いい加減な発言をしてもうしわけない。
>>181
>> 再配置はlink editorとdynamic linkerの両方が扱うもので
>> それぞれの意味が違うってのは大丈夫ですよね？
> それはいいのですが
じゃあ何が通じてないんだろう……。
>> あと.rel.textはアドレス解決には関係ない。
これは自分の発言ではないのでなんとも。
dynamic linkerのレベルでは関係ありません。
link editorがnon-PICなrelocatableからsharedを作る話ですよね？
dynamic linkerがDT_RELやDT_RELAを元に見つけるrelocation tableへ
>>170の例で言うabc用のエントリを作ってDT_TEXTRELを彫り込む、
ってので何が問題だと思います？
0183162
NGNG>>182
>じゃあ何が通じてないんだろう……。
えーと、私もこの前からELFについて勉強し始めたばかりで、
ローダーがどうELFを処理するのかについては、何も知らず、
このスレでも一切触れていません。EXE、DYNともにコンパイル時、
リンク時にどういった処理により作成されるかを、一つ一つ見ているわけです。
>link editorがnon-PICなrelocatableからsharedを作る話ですよね？
私はこの話に関しては何も言ってません。
>>169の「変換しない。」という一言がちょっと気になっただけです。
>>170を見ての通り、non-PICなオブジェクトファイルからDYNを作るとなると、
static変数をGOT経由で参照するようプログラムのロジックを書き変える必要が
あるだろうということ。EXEと違い、DYNにおいてはモジュールローカルな
static変数のアドレスが分らない点にあると思います。いつ、セグメント内のどこに
配置されるのか分らないですから。ローダーの動作を見てないので確かなことは
言えないですが、もし仮にローダーがプログラム内のstatic変数の{絶対、相対}アドレスを
計算してくれるなら、そもそもGOTは必要ないですよね？
GNUのツールはプリプロセッサ、コンパイル、アセンブル、リンクといったフェーズに
キッチリ分けることを重視しているように見えます。そこで疑問なのですが、コンパイル
フェーズで確定したプログラムロジックを後から修正するようなツールなどは
存在するのでしょうか？non-PICとはコンパイラによる最適化の一種だと私は
考えています。そして、non-PICオブジェクトファイルをDYNに含められないのは、
上に挙げたGNUツールの特徴のためだと考えてますがいかがでしょう。
ELFの扱いに関して、ディテールを含めた全体をキッチリ理解したいので、
私の勘違いによる批判、大いにWELCOMEです。
0184デフォルトの名無しさん
NGNG○static変数の参照においてはそもそもGOTは必要ないですよね？
0185156
NGNG> EXEと違い、DYNにおいてはモジュールローカルなstatic変数のアドレスが分らない
dynamic linkerは一意に決められますし、決められないと話になりません。
> もし仮にローダーがプログラム内のstatic変数の{絶対、相対}アドレスを
> 計算してくれるなら、そもそもGOTは必要ないですよね？
効率を無視すればこの状況では必要ありません。
i386でのGOTの使い道は>>166-167にある通りです。
dynamic linkerはsharedを配置するアドレスをプロセス毎に一意に決められますが、
普通は利用するプロセス毎に違うアドレスを使います。
>>170で言うabcのアドレスを特定のプロセスでの絶対番地に変換＝再配置してしまうと、
同じコードを別のプロセスが利用する事が出来なくなります。
それでもプロセス毎にコードのコピーを持ってプロセス毎に再配置すれば、
メモリ領域が無駄になるだけで矛盾無く動作させる事は可能です。
コードを共有するのにはmmap()等を使います。
> コンパイルフェーズで確定したプログラムロジックを後から修正
abcの再配置情報をリンカが作成した上でDT_TEXTRELってフラグをsharedに付けるだけです。
PICに変換する必要は無いのでロジックはコンパイル以降変わりません。
>>184
> static変数の参照においてはそもそもGOTは必要ないですよね？
動けば良いという発想なら必要ありません。
0186162
NGNG>> EXEと違い、DYNにおいてはモジュールローカルなstatic変数のアドレスが分らない
>dynamic linkerは一意に決められますし、決められないと話になりません。
これはリンク時に限定した話です。
>dynamic linkerはsharedを配置するアドレスをプロセス毎に一意に決められますが、
>普通は利用するプロセス毎に違うアドレスを使います。
>>>170で言うabcのアドレスを特定のプロセスでの絶対番地に変換＝再配置してしまうと、
>同じコードを別のプロセスが利用する事が出来なくなります。
・・・
>コードを共有するのにはmmap()等を使います。
おぼろげながらやっと理解できました。straceでローダーの動作を確認してみました。
そこでですが、やはり理解できないのは、
>> コンパイルフェーズで確定したプログラムロジックを後から修正
>abcの再配置情報をリンカが作成した上でDT_TEXTRELってフラグをsharedに付けるだけです。
>PICに変換する必要は無いのでロジックはコンパイル以降変わりません。
上で見た通り、dynamic linkerはメモリ上にプログラムコードを配置する時に
コードに埋め込まれたアドレス値を書き換えることは出来ないわけですよね？
0187162 186の続き
NGNG00000000 <foo>:
0: 83 ec 04 sub $0x4,%esp
3: a1 (00 00 00 00) mov 0x0,%eax
8: 89 04 24 mov %eax,(%esp,1)
b: 83 c4 04 add $0x4,%esp
e: c3 ret
[[[ foo(EXE) ]]]
08048344 <foo>:
8048344: 83 ec 04 sub $0x4,%esp
8048347: a1 (98 94 04 08) mov 0x8049498,%eax
804834c: 89 04 24 mov %eax,(%esp,1)
804834f: 83 c4 04 add $0x4,%esp
8048352: c3 ret
foo.oからEXEを作る上では.rel.textに記載されているRelocation情報をもとに
カッコで囲まれたアドレスを「リンク時」決定することが出来ます。
0x8049498というのは、abcの絶対アドレスだと思われますが、これがリンク時に
確定できるのは、OSが何をどこに配置するのかを、処理系が分っているからですよね？
では、non-PICからDYNを作成するときには
3: a1 (00 00 00 00) mov 0x0,%eax
この一文のアドレス値には何を入れておけばいいのでしょうか？
dynamic linkerがDYNをロードするまではabcの絶対アドレスは確定しない。
dynamic linkerがアドレス値を確定しても、プログラム領域を書き変えるわけにはいかない。
0188156
NGNG> 上で見た通り、dynamic linkerはメモリ上にプログラムコードを配置する時に
> コードに埋め込まれたアドレス値を書き換えることは出来ないわけですよね？
いいえ、出来ます。
例えばmmap()ならMAP_PRIVATEでやってCoWによりプロセス毎にコピーを持つようになるだけです。
メモリの読み取り専用属性は変える必要がありますが。
>>187
> では、non-PICからDYNを作成するときには
>
> 3: a1 (00 00 00 00) mov 0x0,%eax
>
> この一文のアドレス値には何を入れておけばいいのでしょうか？
implicit addendです。
この場合はベースアドレスからのabcのオフセットでしょうね。
jumpのrelocationだと-4だと思います。
0189デフォルトの名無しさん
NGNG>> コードに埋め込まれたアドレス値を書き換えることは出来ないわけですよね？
>いいえ、出来ます。
>例えばmmap()ならMAP_PRIVATEでやってCoWによりプロセス毎にコピーを持つようになるだけです。
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220P\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1183432, ...}) = 0
mmap2(NULL, 1121740, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40066000
mmap2(0x40172000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10b) = 0x40172000
mmap2(0x40176000, 7628, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40176000
close(3) = 0
straceの出力をよく見れば、ld.soによる全てのmmap2(Linux)において
MAP_PRIVATE指定されていました。しかしO_RDONLYでopenして、PROT_READ|PROT_EXECという
保護属性の中で、MAP_PRIVATEというのはどんな意味があるのかな。。。
またMAP_DENYWRITEに関してはmanに以下のように書いてあるのに、ld-2.3.4.soにおいてもまだ
フラグ指定されてるのは、互換性だけの理由かな。
>このフラグは無視される。 (ずっと前は、マップ元のファイルへの書き込みを行おうとすると、
>エラー ETXTBUSY で失敗するようにシグナルが設定されていたが、これは denial-of-service
>(サービス拒否)攻撃の原因となった)
156さんの言ってることがmmapとCoWによりようやく理解できました。
non-PICをDYNに含めることにおいて「効率を〜」という話が出てくるのは
CoWを前提とした話だったのですね。なるほど。
それから考えるとたしかに、DYNにnon-PICを含むことが出来ないのは、
おかしな話に思えます。ELFの仕様が出来上がったのは10年も昔の話だし、
MMUのないCPUなどの事情も考慮されているのかもしれないですね。
他にはGNUツールの開発者のポリシー、またはセキュリティー的な事情とかも
ありうるのかな。ELFを理解できたら、そのうち調べてみたいです。
0190デフォルトの名無しさん
NGNGページごとにCopyが起きるからね。
実際、関数呼び出しがあるページがコピーされたら、
プログラムの領域はほぼ全部コピーされちゃうんじゃない?
0191162
NGNG＞>>185にメモリが無駄になるって書いてあるじゃん。
それは分っています。ローダーがページ境界に収まるように
DYN内の.non-pic.text(仮)セクションをメモリ内にコピー＆アドレス値を
上書きすることでは、それ程無駄になら気も。気のせいかな。。。
ただ、CoWとは言っても、実行が開始される前のdynamic linkerが
コード内のアドレス値を書き換える時点において、ページが割り当てられて
しまうんですね。当たり前ですが。そのコードが実行されるかどうかに関係なく。
最近のOSならばページフォルトを利用したVMMによるファイルの遅延ロードは
どれも実装されていると思いますので、下手したら、静的リンクよりも
効率の悪いものになるかも？！
>実際、関数呼び出しがあるページがコピーされたら、
>プログラムの領域はほぼ全部コピーされちゃうんじゃない?
これはどういう意味ですか？できればもう少し詳しくお願いします。
先にPICなセクションを再配置しておいてから、non-PICなセクションを
処理すれば、あまり問題がないような。
DYNにnon-PICなコードを含めるのならば、セクションを別にする必要が
あるだろうと思います。
不勉強なのに適当な印象の話ばかり書き込みました。しばらくELFと
dynamic linkerについて調べてきます。
0192156
NGNGちょうどcygwinでi386のelfを吐けるクロスコンパイラをビルドしたところだったので
試しにやってみたらnon-PICなrelocatableからsharedを作れました。
# ていうか最初に試せ ＞俺
>>142の人がどういう手順と環境で出来なかったのか気になります……。
0193デフォルトの名無しさん
NGNGおお、それはGOODニュースですね！
で、できればリンカオプションを教えてください・・・orz
0194162
NGNG$gcc -c -fomit-frame-pointer -o foo.o
$ld -o foo.so -shared foo.o
$objdump -d foo.so
000002b8 <foo>:
2b8: 83 ec 04 sub $0x4,%esp
2bb: a1 c8 12 00 00 mov 0x12c8,%eax
2c0: 89 04 24 mov %eax,(%esp,1)
2c3: 83 c4 04 add $0x4,%esp
2c6: c3 ret
なんか今まであれこれ憶測並べてたのが恥かしくなってきた。
もう寝る。。
0195156
NGNG> DYNにnon-PICなコードを含めるのならば、セクションを別にする必要がある
まるっきり勘で言いますけど、普通別にしないような気がします。
まあ勘なんでなるたけ突っ込まないで下さい。
あと細かい点ですが、実行時の視点で見るのはセクションでなくセグメントです。
ELFの場合この用語は混同しない方が良いです。
>>194
すんません、普段ELFを作れる環境を使わなかったんで……。
Sunのサイトで公開されてるSolarisのマニュアルにリンカに関する物があって、
それにELFの仕様の邦訳っぽい物も含まれてます。
所々微妙な訳もありますけど、一応メンテナンスはされてるようなんで
英語がとっつき辛い場合はそれも参考にすると良いかもしれません。
0196デフォルトの名無しさん
NGNG0197鬼塚先生
NGNG0198デフォルトの名無しさん
NGNGそれはGTO。
0199デフォルトの名無しさん
NGNGld -T boot.ls -o boot boot.o
したら
ld: PE operations on non PE file.
というエラーになって生成できません。
AMD k6-2のLinuxではちゃんとブートセクタが生成されて動作できました。
Cygwin版特有のオプション等が必要なんでしょうか？
解決方法を教えて下さい。
よろしくお願いいたします。
boot.ls
-----------------
OUTPUT_FORMAT("binary");
MEMORY
{
body : org = 0, len = 510
sign : org = 510, len = 2
}
SECTIONS
{
.text : { *(.text) } > body/* executable code */
.rodata : { *(.rodata*) } > body/* constants */
.data : { *(.data) } > body/* initialized data */
.bss : { *(.bss) } > body/* uninitialized data */
.sign : { SHORT(0xAA55) } > sign/* boot signature */
}
0200デフォルトの名無しさん
NGNGboot.oはどうやって生成した?
0201199
NGNGMakefileの内容です。
all:
gcc -Os -c -o img/boot.o boot.s
ld -T img/boot.ls -o img/boot img/boot.o
gcc -Os -c -o img/kernel.o kernel.c
ld -T img/kernel.ls -o img/kernel img/kernel.o
dd if=img/my_default.img of=img/my.img 2> /dev/null
dd if=img/boot of=img/my.img conv=notrunc 2> /dev/null
dd if=img/kernel obs=512 seek=1 of=img/my.img
0202デフォルトの名無しさん
NGNGどっちかだと思ったんだよな。
ldのメッセージは前者っぽいんだけど
gccがcygwinネイティブなら後者かなー。
今携帯からなんでPEのリファレンスがねーのよ。
0203199
NGNGばいなりエディタでboot.oを各環境とも開いてみたらLinux側は先頭に
.ELF
があって、Cygwin側の先頭は
L<
text
って感じでした。
自分ではこれが何を意味しているか分からないですが参考までに。
よろしくお願いいたします。
0204デフォルトの名無しさん
NGNGリンカスクリプトのboot.lsが元のオブジェクトファイルの中から
.textセクションとか.rodataセクションを抜きだして
(セクション構造のない)ベタなbinaryにしようとしてるわけだけど、
このセクション構造がELFにあってPEにないもので、
cygwinで作ったバイナリがPEなもんだから
ldが処理できませーんとかになってんじゃないのかなみたいな
0205デフォルトの名無しさん
NGNGして詳細メッセージ出したのをはってもらえない?
0206199
NGNG$ ld -v -T img/boot.ls -o img/boot img/boot.o
GNU ld version 2.15.91 20040725
ld: PE operations on non PE file.
0207199
NGNG$ ld -V -T boot.ls -o img/boot boot.o
GNU ld version 2.15.91 20040725
Supported emulations:
i386pe
ld: PE operations on non PE file.
となりました。
0208デフォルトの名無しさん
NGNGhttp://my.execpc.com/~geezer/embed/bugs.htm#mingbug
0209デフォルトの名無しさん
NGNG超簡単なmsvcrtの関数使うサンプルとかないですかね？
そういや市販コンパイラが作るDLL関数の呼び出しコードって
インポートテーブルから
call DWORD ptr[import_table_address]
のようなことしてるけど、別に
mov eax, procedure_addres
call eax
としてもいいよなあ。
なんで１段参照増やしてんの？
インポートテーブル分無駄じゃない？
0210デフォルトの名無しさん
NGNGなるほどねー。
0211デフォルトの名無しさん
NGNGの各DLL関数名の前に付いている、
「ヒント」の値って、何を入れるんでしょうか？
意味がまるでわからないです。
0212デフォルトの名無しさん
NGNGどうせ名前で調べるし
0213デフォルトの名無しさん
NGNGこんなのどうやって知るのでしょうか。
参照するDLLを調べろということですかね。
どっかから入手したpecoff.docによると、
>6.4.3. Hint/Name Table
>Field Hint
>Description
> Index into the Export Name Pointer Table.
> A match is attempted first with this value. If it fails,
>a binary search is performed on the DLL's Export Name Pointer Table.
ということは、わかんなかったら0とかの適当な値でよいと言う事でしょうか。
試しに全部0にしてやったらうまくいきました。
このヒントは、パフォーマンス上の理由でしかないのでしょうか？
0214デフォルトの名無しさん
NGNGそうですね。
実験してとりあえず無視して問題なかったので、
しばらく放置プレイしときます。
0215デフォルトの名無しさん
NGNGリンカであらかじめ序数を控えておいた方が良いのかな。
DLLの関数を全部列挙するなんてAPIないですよね・・・。
objdump.exeで取ってくるしかない？
0216デフォルトの名無しさん
NGNG同じことだけど PE 解析ルーチンを書けばいい。
0217デフォルトの名無しさん
NGNGそれとexe自体よりスタートアップ作るのが面倒すぎる。
Win32APIしか使わないなら話は簡単だけど、
Cランタイム使えないとあんま意味ないんだよなあ。
とりあえずmsvcrt.dllを安全に使えるレベルとか考えてたけど
無理な気がしてきた。
mingwやlccwin解析すりゃいいんだろうけどね。
すげー遠い。
素直に既成のリンカへ.obj渡す事考えた方が早いかも。
0218デフォルトの名無しさん
NGNGという連載が始まったよ。
今回は13Pで、主に用語など基礎知識の説明でした。
次回はELF形式のお話みたいなんで期待。
0219デフォルトの名無しさん
NGNGInterfaceのこの手の記事は使えそうで使えないからなあ。
ELF形式なんてGNU系の資料いっぱいあるからPEやって欲しいのだが。
PEやる予定あるのかな。
無かったら笑えるがな。
0220デフォルトの名無しさん
NGNG0221デフォルトの名無しさん
NGNG0222デフォルトの名無しさん
05/02/05 10:26:280223デフォルトの名無しさん
05/02/06 03:09:02実行ファイルを作成した場合、必ずどっちが優先されるとか
ってあるんでしょうか？
0224Rubyist!
05/02/06 03:12:030225デフォルトの名無しさん
05/02/14 14:21:01内容上重複というか同じような事書いてる部分は多いかもしれないが
読んで楽しめるとは思う
ちなみにLinker"s"
sが付く、これ重要
どうでもいいが漏れの近くの書店ではHTMLの分類の所に
隣近所はHTMLとかホームページとか
田舎の書店のアルバイトじゃ分類タイトルみただけじゃそうなるだろうなぁ
0226デフォルトの名無しさん
05/03/05 05:38:080227デフォルトの名無しさん
05/03/05 05:49:40オタ本の分類だろうし
少なすぎるというかそもそもたくさんある類いの本じゃないよね
0228226
05/03/05 06:05:41もっと美しく言うと専門書籍って言わない？(萌え本みたいな印象もあるし)
0229226
05/03/05 06:21:23みんな(出版社とか)は、わかって無いよなぁ。チャンスなのに。
0230デフォルトの名無しさん
05/03/05 06:42:57萌え本ってなんですか？
0231デフォルトの名無しさん
05/03/05 08:36:54http://www.google.co.jp/search?hl=ja&q=%E8%90%8C%E3%81%88%E6%9C%AC&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja
0232デフォルトの名無しさん
2005/05/26(木) 21:34:03×ぶっちゃけ、「Linkers & Loaders」のような本が少なすぎる。
○ぶっちゃけ、「Linkers & Loaders」のような本を読む人が少なすぎる。
0233デフォルトの名無しさん
2005/05/26(木) 22:02:200234本田& ◆xOS3wf.pJg
2005/05/27(金) 01:11:58PEフォーマットってCOFFフォーマットの別名だよ。
0235デフォルトの名無しさん
2005/05/27(金) 19:17:49L&LかInterfaceの連載くらいしか見たことない。
>>234
PEとCOFFは同一ではないから、別名というのは違う。
COFFを拡張したのがPE。
0236デフォルトの名無しさん
2005/05/28(土) 22:18:450237デフォルトの名無しさん
2005/06/25(土) 21:26:29いったいこれは何なのか。
私の書いたmain以外のstartとかendとかいったシンボル名は何なのかと。
0238デフォルトの名無しさん
2005/06/25(土) 23:22:56ソース見たほうが早いよね
0239デフォルトの名無しさん
2005/06/25(土) 23:50:58ソースがあるといいね。
0240デフォルトの名無しさん
2005/06/26(日) 00:27:02ただの entry point でしょ。
>>239
何でソースが無いと思ったの?
0241239
2005/06/26(日) 01:04:27crt0.oなんて名前はありきたりで環境が分からないから。
0242237
2005/06/26(日) 09:42:430243デフォルトの名無しさん
2005/06/26(日) 15:20:31いっぱいあるよ
0244デフォルトの名無しさん
2005/06/26(日) 15:32:33crt0ってのは（名前からすると）Cランタイムライブラリを初期化するためのコードで、
Cランタイムライブラリに依存するもの（≒Cコンパイラに依存するもの）。
ライブラリ（コンパイラ）のマニュアルに書いてあるかもしれないし、
コンパイラセットにソースコードが付いてることもある（少なくともMSVCには付いてる）。
0245デフォルトの名無しさん
2005/06/26(日) 15:36:410246デフォルトの名無しさん
2005/06/26(日) 16:27:580247デフォルトの名無しさん
2005/06/26(日) 16:55:090248237
2005/06/26(日) 23:49:070249デフォルトの名無しさん
2005/06/27(月) 00:32:080250デフォルトの名無しさん
2005/06/27(月) 08:51:190251237
2005/06/27(月) 22:21:580252デフォルトの名無しさん
2005/06/27(月) 23:35:470253デフォルトの名無しさん
2005/06/28(火) 01:07:570254デフォルトの名無しさん
2005/06/28(火) 17:46:07一応、適当なリンクを貼っておくが。
http://pc8.2ch.net/test/read.cgi/tech/1058134693/726-
0255237
2005/07/02(土) 19:27:180256デフォルトの名無しさん
2005/07/03(日) 04:05:18無能は震えながらではなく、藁のように氏ぬのだ。
0257デフォルトの名無しさん
2005/07/03(日) 14:35:28そういうの恥ずかしいから辞めようよ
0258デフォルトの名無しさん
2005/07/03(日) 18:39:57【鉄則】アホはスルー
0259デフォルトの名無しさん
2005/07/04(月) 15:02:230260デフォルトの名無しさん
2005/09/18(日) 16:41:50リンカからコンパイラ、アセンブラまで作ったが
さすがにOSはアホらしいな。
0261デフォルトの名無しさん
2005/11/24(木) 04:18:36もしかしてWindows付属のDLLって全部アドレス空間のどこにマップされるか、
最初から全部決まってるの？
0262デフォルトの名無しさん
2005/11/24(木) 06:46:410263デフォルトの名無しさん
2005/11/24(木) 10:53:100264デフォルトの名無しさん
2005/11/24(木) 16:38:48￣￣￣￣￣∨￣￣￣ (´´
∧∧ ） (´⌒(´
⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
￣￣ (´⌒(´⌒;;
ｽﾞｻﾞｰｰｰｰｰｯ
0265デフォルトの名無しさん
2005/11/24(木) 17:15:11それはもちろんそうなんだけど、仮想アドレス空間の無駄使いじゃない？
0266デフォルトの名無しさん
2005/11/24(木) 17:42:10ページは4kバイト単位なのでそうでもない
それに指定されたページにロードできなかった場合でも違う場所に割り当てられる
0267デフォルトの名無しさん
2005/11/24(木) 23:06:29世の中の大半の用途では、物理メモリはともかく
アドレス空間ケチるほどメモリ使わないので問題ない。
0268デフォルトの名無しさん
2005/11/24(木) 23:12:050269デフォルトの名無しさん
2005/11/24(木) 23:16:14くやしく
0270デフォルトの名無しさん
2005/11/24(木) 23:56:56＞それに指定されたページにロードできなかった場合でも違う場所に割り当てられる
え、じゃあ例えば、俺の使ってるWindowsのNTDLL.DLL、
ImageBaseは0x77f80000という値になってるけど、これは
別の場所に再配置することも可能なの？
0271デフォルトの名無しさん
2005/11/24(木) 23:57:00ELFへの移行は
・共有ライブラリが作りやすい
・動的リンクがやりやすい
・クロス開発がやりやすい
・C++対応（コンストラクタとデストラクタ）
が主な理由。
64bit対応ってのは（当時と今は）あまり重要ではない。
未来は知らんが。
0272デフォルトの名無しさん
2005/11/25(金) 00:07:06DLLは基本的に再配置するものなので、必ず再配置セクションを持つ。
NTDLL.DLLも再配置セクションがあるので（dumpbinで覗いてみ）、
必要なら再配置できる。
0273デフォルトの名無しさん
2005/11/25(金) 01:32:46それだとImageBaseを固定するメリットってあんまりなくない？
0274デフォルトの名無しさん
2005/11/25(金) 02:31:37適当なアドレスに固定してるんじゃなくて、
一通りメモリに読み込んで再配置完了したのと同等のアドレスにしてある。
アプリ起動のたびにほぼ必ず読み込まれるシステム系のDLLを
毎回再配置しないで済む分、起動が速くなる。
0275デフォルトの名無しさん
2005/12/21(水) 10:46:27とりあえず、ヒントくれ
0276デフォルトの名無しさん
2005/12/21(水) 13:35:48objcpy
0277デフォルトの名無しさん
2005/12/25(日) 19:40:34Cygwin/Mingwが吐く relocatable object file は
MS環境でもリンクできる。
なので objcopy 最強。
0278デフォルトの名無しさん
2005/12/25(日) 23:37:14例えば
elf32-i386 -> elf32-powerpcle
とか。
0279デフォルトの名無しさん
2005/12/26(月) 00:50:29できたと思った。昔configureして
ぜんぶ入りのobjcopyを作ったことがある
0280278
2005/12/26(月) 16:09:38できないお ＞_＜
$ objcopy -I elf32-i386 -O elf32-powerpcle foo foo-ppc
objcopy: Warning: Output file cannot represent architecture `i386'
targetにはちゃんと入ってるお
$ objcopy 2>&1 | tail -1
objcopy: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux efi-app-ia32 elf64-little elf64-big
elf32-little elf32-big elf64-alpha ecoff-littlealpha elf32-hppa-linux elf32-hppa elf64-ia64-little elf64-ia64-big
efi-app-ia64 elf32-m68k a.out-m68k-linux elf32-powerpc aixcoff-rs6000 elf32-powerpcle ppcboot
elf64-powerpc elf64-powerpcle aixcoff64-rs6000 elf32-s390 elf64-s390 elf32-sparc a.out-sparc-linux
elf64-sparc a.out-sunos-big srec symbolsrec tekhex binary ihex
0281デフォルトの名無しさん
2005/12/27(火) 20:48:330282デフォルトの名無しさん
2006/02/17(金) 13:52:54１時間以内に返答が無かったら賛同してくれるものと見なす。
0283デフォルトの名無しさん
2006/02/17(金) 14:14:27まさか、単なる保守 age じゃないよね??
0284デフォルトの名無しさん
2006/02/17(金) 14:17:11ネタはないですね。そろそろ落ちるんじゃないかと思った。
しいて言えば本購入予定です。ハイ。
0285デフォルトの名無しさん
2006/02/20(月) 11:25:050286デフォルトの名無しさん
2006/02/21(火) 10:47:360287デフォルトの名無しさん
2006/04/25(火) 10:08:260288287
2006/04/25(火) 13:37:56.so → .lo
というlibtool版か。
.soはあるのに、.laがなくなると起動しなくなるものがあるって事は、
.laをdlopenしているアプリがあるのかな。
0289287
2006/04/25(火) 16:17:410290デフォルトの名無しさん
2006/04/28(金) 22:50:10そーそー、textファイルだから、開けてびっくりするよな。
libディレに、んなもんイッパイ入れんな！と、最初思ったよ。
0291デフォルトの名無しさん
2006/08/24(木) 07:04:11わかるやつおらんかね？
さっぱり意味のわかる資料がない
自分でリソース追加したいんだが
0292デフォルトの名無しさん
2006/08/24(木) 22:16:10■ このスレッドは過去ログ倉庫に格納されています