Linker && Loader

読んでる人いますか？
難しいような気がするんですが。。。
僕もリンカとローダを作れるようになれますか？

>>2ｹﾞｯﾄずざー！！
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

2ちゃんねらにはレベル高すぎたかな？

リンカくらいならわりと簡単に作れるんじゃない？
とりあえずcomからはじめるがよろし。

需要があるのだろうか5ｹﾞﾄ

そのものズバリの本があるんだから
それ読み終えてから出直してこい、ボケ

6は馬鹿ですか。隣家も牢打も仕様の塊、根気があればできるんじゃない？

>>1
せめてこれぐらいのことはしろよ。

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

燐火をわざわざ自作する意義を教えれ。

>>9
理解のため……とか。

>>9
ローダ作るためにはリンカ作れるくらいの理解があったほうが良かろう。

オブジェクトファイル形式とABIってのはどう違うの？

♪リンカカリンカカリンカガヤ〜

コレ嫁とは言わんが、C/C++やるﾔｼは、コンパイラとリンカの仕組み位は知っててﾎｽｨ。
Lib不足でﾘﾝｶｴﾗｰになってるのに、必死でｺｰﾄﾞ見直してるの、見てらんない。

ひげぽんの為にあげ

IDE&RADのせいだな。10年前にはそんなこと考えられなかった。

●●●●●●●●恒例・「オセロさえ納期内に作れない＝ＯＯ役立たず 」祭り●●●●●●●
http://pc3.2ch.net/test/read.cgi/tech/1032985885/l50
／|　　　　　　 　 |　 |＿＿＿＿_ΦΦΦΦΦΦΦΦΦΦΦ||ΦΦΦ
　 |　　　　　　 　 |　 |￣￣￣ ／|　　　　　 　 　 　 　 　 　 　 ||
　 |　　　　　　 　 |　 |　　　／ ／|TTTTTT　　 TTTTTTTTTT||TTTTT
　 |　 　 　 　 ／＼　|　 ／|／|／|^^^^^^ |三三| ^^^^^^^^^^^||^^^^^^^
　 |　 　 　 ／　 ／　|／／ ／ ／|
　 |　　　／　 ／ |＿|／|／|／|／|
　 |　 ／　 ／　　|文|／ ／／ ／
　 |／　 ／.　 ＿.|￣|／|／|／　　　　　　　　　Λ＿Λ
／|＼／ 　／　／ 　|／ ／　　　　　　　　　　 （＿＿_）
／|　 　 ／　／　 ／ヽ　　　　　　　　　　　　/〔 非OO 〕〕つ
　 |　　　|￣|　 |　|ヽ／l　　　　　　　　　　　 ｀/二二ヽ
　 |　　　|　 |／|　|__|／　　　Λ＿Λ　　　　 /　/（＿）
　 |　　　|／|　 |／　　　　　 （　´∀｀）　　　（＿）　　　 Λ＿Λ
　 |　　　|　 |／　　　　　 ／/ /　 ^￣］ﾟ　　　　　　　　（｀　　　）

14は実務経験者と名乗っているがひっきーだな。
実務経験してるとは思えん発言だ。

test

リンカからコンパイラ、アセンブラまで作ってOSつくる
これぞ漢

>>20
> これぞ漢

漢なら、CPU から作れや。

>>21
神をめざすなら、物理法則から作れや。

でも無理だからコンピュータ上でやれや。

そして再帰レベル2へ…

>>21
最近はFPGAで手軽にCPUも作れますなぁ
>>22
地球シミュレータで手軽につくれますなぁ（これは嘘）

からage からage!

保守

>>20-13
実に中学生っぽい発言（ｗ

>>14

C++ だとコードのミスがリンクエラーを誘発する事が有るんだが。

（テンプレートの実体参照と extern "C" に要注意）

>>27
Libが無いというエラーに対して、と書いてますがな。
ちゃんと細かい所まで見ないと。
ｱﾝﾀみたいなのが>>14に書いてあるような失敗するんでっせ。

普通「Libが見つからん」と言われたら、リンクオプションの
設定ミスを疑う罠。

>>27-29

>>14 は Lib 不足でリンカエラーと書いているので、
Lib が見つからないのとは違うのでは。

ほんとに Lib 不足かどうかはリンカにはわからんので、
足りないシンボルを人間が確認する必要がある。
ライブラリに有るはずのシンボルが見つからないなら、
当然 Lib 不足。
コード中にあるはずのシンボルが見つからないなら、
>>27 の原因も調べる必要がある。

で、14 は原因が Lib 不足とわかっていたようだが、
必死になっているヤツに教えてあげたんだろうか。

隣家エラー

さてどれでしょう。 (2点)
(1)後ろでﾆﾔﾆﾔ笑ってた
(2)Libが無いんじゃないかと小一時間
(3)放置プレー続行
(4)ものすごい勢いでｷｰﾎﾞｰﾄﾞ強奪してオプション修正
(5)悩んでたのは自分ﾃﾞｼﾀ!

１！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

hage

IP取られるのがいや？そりゃそーだよ。
ニフティの掲示板なんかじゃ、ちょっと口論になっただけで訴えれらたじゃん。

>>8　お前アホじゃん？

↑こーいう発言もこれからは慎重にしないと・・・・。

あ、でも警察じゃないとIP提出しないんだっけか？じゃぁ各種団体には提出しないのかな？無理だと思うぜぇ

基礎英語聞かなくっちゃｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

俺は　自宅---イスラエル---インド---中国---北欧---カナダ---エジプト---自宅---２ちゃん

と20もの多弾プロ串を経由しているので追跡は不可能です。

　　　／⌒ヽ　
　　/　　´_ゝ`） 　ＩＰ太郎です。
　　|　 　　/　　　
　　| /|　|　　　
　 //　| |　　
　Ｕ　 .Ｕ

記念ｶｷｺ

ヤフーの投票文、「2ちゃんねるがアクセスログ記録を始めましたが何か？」にしてﾎｽｲ。

>>41 それは、「特定電気通信役務提供者の損害賠償責任の制限及び発信者情報の開示に関する法律」
が施行されて以降の話ですよね。

>>40 ま、一部事実誤認があった事は認めますが、趣旨は間違って無いと思いますよ。
判決文を、もう一度よく読んでみることにします。

http://courtdomino2.courts.go.jp/kshanrei.nsf/$DefaultView/2075F93E3210745849256BED0030F3EF?OpenDocument

この判決文のなかに「内容証明がなんとか」ってのは書いてあるかってことだな

>>657
あぁ、びっくりした。W2Kでﾊｲｽﾍﾟｯｸだから切り抜けられたけど。
いやはや・・・98とか使っている人はひらかないほうが無難。
java scriptは便利なんだけどねぇ・・・こういう使い方は(・A ・)ｲｸﾅｲ!

>>317 >>322
法的な面をクリアーするのはそれほど難しくないと思います。
ただ、それをどうペイさせるかはかなり難しい予感。
管理者のハードルが高くても、参加者のハードルが低ければ問題ないので、
１つや２つくらいは誰かがやってくれるんじゃないかなと淡い期待。

一方で現在のところ、２ちゃん以外の掲示板的コミュニティーは、参加者のハードルを
高くすることで２ちゃんの抱える問題を解消しようとしている点で、限界が見えている。

別にいいじゃん。個人のサイトだって掲示板書けば取られるし
IP表示せんと書けない掲示板なんていっぱいあるし
アクセス解析で取られまくりだし。むしろ今更何があかんの？て感じ

IP取られてもいいから
アホニシを何とかして欲しいよ。

(･∀･)ﾆﾔﾆﾔ

言いたいことも言えないこんな2chじゃ

俺達モーヲタには全く関係の無い話だなｗ

ウザとかって、もしかして真剣に聞いてたのか？
正直すまんかった。厨は早く寝てね。

http://ex.2ch.net/test/read.cgi/korea/1042022029/

在日のアサピーが自ら２CHにブラクラ貼ったと自白ｗｗｗ

調子に乗ってアタック開始、しっかりログ取られて通報すました。

祭り中です。

さん
10桁トリップの時に、トオルさんとマァヴさんが、話してましたわね、

======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 139038人　発行日：2003/1/10

なにやら、連日メルマガだしてるひろゆきです。

そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。

重くなって落ちたりしてもご愛嬌ってことで。。。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

　　　メリットがなくなったね。もう来ないよ。ヤフーにもどろ。

さん
ですわね。

あーーーーーーくだらねえ

将来は衛星にサーバ置いて法律が及ばないようにしよう

内部告発されるようなことをするのが悪いと思うが。

8 名前： ひろゆき＠管直人 投稿日： 2000/04/07(金) 07:20
あ、そそ。それをいいたかったのよ。
つまりね、
ここ、一般の人は見れない板だからいっちゃうけど、
将来的にはすべてＩＰ取るようにしたいし、
もっと商業的な板にしたいと思ってる。
ヤフーに勝ぐらいのつもりでね。
だけど、今そういうスタンスを取ると、人が離れるだけだから、
表面ではＩＰとらないことをウリにして、
人があつまって、収益の見込みが立ったら
犠牲者でも出して、綱紀粛正するつもりなんですよ。

あ、でもこれあくまでオフレコだから、
内緒ですよ。
この板見れる人なんて決まってるんだから、
ばらしても無駄ですう。

600,000,088

さいたまに住んでいます

なるわけねーだろ　
馬鹿はしねよ

こんなので動かされる関係者はかわいそうだよな。
もしなんかあったとき、対策とってなかったら叩かれ
るのも関係者だし。

仕事ですから。

横浜地方裁判所第４民事部でも12/13掲示板訴訟判決。

そっか、俺の認識が甘かった。
ドリキャスをネットにつないでる人って全ブラウザの数％を占めていたのか。

age

（＾＾）

そうだね。

（＾＾）

（＾＾）

2ちゃんねらにはレベル高すぎたかな?

ｵﾝﾗｲﾝ版を読んでるが平行して読んでる本が沢山ありすぎてまだ3章だ。
保守あげ

（＾＾）

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

ﾎｼｭ

>>14
概念や理論だけは理解しろといいたいんだろ？

必ずしもこれを覚えなければ何もかも全くできない状況は
減りつつあるし

半年も前の煽りにﾚｽですか。

>>81
質問混じりのレスと煽りを一緒にするとは

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

2ちゃんねらにはレベル高すぎたかな?

>>1
いまのところこいつを詳しく知らないとプログラミングに困る状況がないんですが。
本に書いてある内容も、新しい言語では殆ど自動化されて
メモリ節約以外ではそんなに意識する必要瀬がないんではないかと。

>>85
ふつーにアプリケーション作るなら、
こんな本読む必要はないでしょう。
雑学として覚えておいて損はないと思うけどね。

こんなことで威張ってる香具師は古典的なのか？

こんなことしりたがってる香具師は新しい言語でも作る気か？

いまから新しい言語をつくるよりも既存の言語用にフレームワークを開発しているほうが
ましだろ。

コンパイラ付きの開発環境でも作ろうと思ったら
必須の知識だと思うが。
新しい言語だろうがそうでなかろうがな。
例えば、ActiveBasicの作者はこういう知識をもってるだろうし、
もっと華やかな所で言えば、gccやJavaなんかの開発チームは
こういう知識が必要だろ。

>>88
結局コンパイラを作りたいんじゃないかい。

作らない香具師には知識が増えるだけで関係ないって凝った。

ローダってOSが担うんじゃないの？

OSつくるわけじゃないから関係ない
OSつくるよりもその上で動くアプリケーション作ったほうが効率がよろし

OSでなくても、宗教上の理由で標準の動的リンク機構を使えないとか、
なぜかELFなsoをwindowsで使わないといけない状況では、必要な知識でしょう。

そんな状況に直面する事は滅多に無いと思うが。

>>89
ある人には関係あって、ある人には関係ない。
自分に関係ないからって、他人に文句言うのは筋違いだろ。
コンパイラ作るのが有意義な人だっているんだよ。

死滅スレでPEのことを威張っていた奴はどうしたのだろうか

ELFのフォーマルな仕様書って
http://www.skyfree.org/linux/references/ELF_Format.pdf
これだけ？
それからELFの表現し得るすべてをldやそのリンカスクリプトで表現できるの？
（できないものを現したいときは、バイナリエディタか？ｗ）
どっちにしてもELFのフォーマルな仕様書が仮にあったとしても、
その主な実装系たるGNUツールが対応してなければ、意味がないということか。。。

http://homepage.mac.com/hiroyuki44/

おまいらよ、リンカをつくるのに「Linker && Loader 」を読む必要はないよ。
リンカをつくるのは、OMFやHEXのフォーマットを知っていれば充分だよ。
OMFはHEXのフォーマットは前はインテルのサイトからDLできたけど、いまはできないようだよ。
あと、ローダはWindowsが勝手にやってくれるから、つくる必要はないよ。

そりゃ、初めからリンカやローダーの仕組みを知ってる人はそうだろうよ。

新しいオブジェクトファイル形式をでっち上げて、
それに対する、カーネルモジュールからローダー、リンカ、アセンブラ
なんかのツールを作ればかなり勉強になりそうだ。
誰かやったことある人いる？

100age

今IT

JavaではJavaCCでコンパイラをつくるとき以外はリンカの知識は不要？

JavaCC は構文解析部を生成するツール。
リンカの知識が必要なのはコード生成部なので、
なぜJavaCCと特定しているのかわからん。

>>102
JVM の内部に手を突っ込みたいなら必要。

age

http://homepage.mac.com/hiroyuki44/

>>91
アプリケーションプログラマーなんて、ツクールでＲＰＧをつくってるやつと一緒でエンジニアとは言えないな。
ツクールそのものをつくるのがエンジニア。

>>95
今揉めてるSCOだけど、ELF、というかもう少し広く考えて
UNIXのABI全般に関しては一応ここかと
http://www.caldera.com/developers/devspecs/

>>107
ツクールもアプリケーションだと思うけど･･･

>>107
お前は一生機械語だけでコーディングしてろ！

でわ某L氏はエンジニアの鑑ですね。

実行ファイルをRAM領域にコピーしてそこにジャンプしたいんで
だれかあぼぼぼ

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

Delphi 最強

（＾＾）

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

age

>>さわむら
だろうな。
ひげぽんにおせーてやれ。
藻前の作ってるＯＳにﾛｰﾀﾞはいらねぇとな。

むかーしさわったOS/９ちゅーOSは
ローダーっつー概念がなかったな。
（その後のバージョンはしらん）

つまりファイルイメージ=メモリイメージ だ。

完全リロケータブルなバイナリコードを前提として
ディスクからメモリに読み込むだけで
アドレスの解決は一切しない。
PC相対アドレッシングが強力な6809だからできたんだろうけど
（同じ命令でもPC相対のほうが早かったりした
80系でそんなことしたらえらい非効率だったろう。）

あと、ファイルイメージをそのままROMに焼けたりした。

起動プロセスがメモリマップをチェックして
マジックナンバーを見つけると
勝手にモジュールを認識してくれたりした。

リンカとかローダーとかをお勉強すると、
C言語にはとってもとっても難しくって出来ない事が、
簡単に出来ちゃうから面白いよ。
外部結合の識別子を日本語に直してみたりね。

保守

・本体：GBA-SP
・ケーブル：Flash2Advance USB Linker
・ソフト：Flash2Advance Writer 3.1 Win9x/Me/NT/2000/XP (28-07-2003)
の組み合わせで手持ちのGBAのロムを吸い出そうと
しているんですがstartとserectを押しながら電源をonすると
Flash2Advance Writer 3.1がフリーズしてしまいます。
また本体側も認識した時特有の画面になりません。
デバイスマネージャーでUSBのドライバは認識しているよう
なんですが。
どのような不具合が考えられますでしょうか？
初心者の質問ですいません。
よろしくお願いいたします。

(ﾟДﾟ)ﾊｧ?

>>122
あなたの脳味噌が不正な処理を行っています。
最新の物を再インストールして下さい。

ローダーを勉強しようと思い、glibcのelf/*を
見たら、テストコードがぐちゃぐちゃに入ってて萎えた

elfロダだったらmonaでも見てみれば？
間違ってるかもしれんけどｗ

gccスレから勝手にこっちに来たけど、

>>613
>関連ドキュメントが少なすぎるぅぅぅ（泣

MINIXの本とか読んでみたら?
タンネンバウムのOSの本とかさ。
昔のbitには良くこんな記事があったんだが。
(図書館でバックナンバーを読んだ)

GCCスレから誘導されてきました。
自分は今、「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には良くこんな記事があったんだが。
>(図書館でバックナンバーを読んだ)
むむっ！！見たい！知りたい！どこにあります？

．．．．．．．．．。
あれ？
やっぱ誰も見てないんじゃないだろうか？＞このスレ
鬱だ。

ttp://www.borland.co.jp/bcsuite/tc40j.html
ここのVROOMMというのは違うのかな？

>>128
loaderなかったら、program実行できないじゃない。

>>128
> GCCスレから誘導されてきました。
(略)
> この部分は誰が（どこが）その処理を担当をするのか？

人がやるかソフトウェアがやるかは環境によるよね。
オーバーレイだから、組み込み系の人に聞くんがいいんじゃない?

GCCスレに書いたけど、それやるアセンブラ、リンカ使ったことあるよ。
大型で動いていたHLISPってLispの処理系も自分でやってたね。
アドレス空間が狭かったからね。

>>128
共立出版の雑誌"bit"は、
大学の図書館(工学系)行けば必ずある。

bit...
良い奴等はみんな氏んじまった。

よい雑誌で生きのこってるのって何？
文系PGにはTransTechみたいな雑誌が丁度いいかと
思えたけど、あれも直ぐ潰れちゃったよね。
結局コボラー相手の雑誌しか生きのこれないということか。

あれ。いつのまにやらレスが。

>>130
>ttp://www.borland.co.jp/bcsuite/tc40j.html
>ここのVROOMMというのは違うのかな？
そうかもしれませんが、どうやってるのか知ることができません。Borlandの独自技術かな？

>>131
>loaderなかったら、program実行できないじゃない。
それはそうですけど、loaderやlinkerに関しての理論や説明が無いってことでした。

>>132
>人がやるかソフトウェアがやるかは環境によるよね。
>オーバーレイだから、組み込み系の人に聞くんがいいんじゃない?
>GCCスレに書いたけど、それやるアセンブラ、リンカ使ったことあるよ。
>大型で動いていたHLISPってLispの処理系も自分でやってたね。
>アドレス空間が狭かったからね。
なるほど、ありがとうございます。
うーむ、どうも最近それほどオーバーレイにこだわる必要はないんじゃないかって気がしてきました。
使用範囲が限られてるようだし．．だから次の章に進んでます。

>>133
>共立出版の雑誌"bit"は、
>大学の図書館(工学系)行けば必ずある。
学生ではないんですが、一般の人でも入れるんですか？

文明が発達すると、人の能力も落ちてくるんじゃないのかな。
ゼロから全てのソフトを書き上げる能力を、皆が持っていた
時代から比べれば、今のPGはアホウの集まりのようだ。

原始人て、もの凄く頭悪そうなイメージがあるけど、実はかなり
賢い生き物だったのかもしれないね。生きるための創意工夫を
独自に発案できない椰子は生きていけない世界だったのかもしれない。

>>137
>文明が発達すると、人の能力も落ちてくるんじゃないのかな。
>ゼロから全てのソフトを書き上げる能力を、皆が持っていた
>時代から比べれば、今のPGはアホウの集まりのようだ。
>原始人て、もの凄く頭悪そうなイメージがあるけど、実はかなり
>賢い生き物だったのかもしれないね。生きるための創意工夫を
>独自に発案できない椰子は生きていけない世界だったのかもしれない。
そうですね。
人間って弱い生き物なので、一度うまくやってしまうとだんだんと楽をしようとしてしまって、
楽な方へ楽な方へと流されてしまう。
そして気づいたらそれをどうやってすればいいのか、どうなっているのかすらわからなくなってしまっている。
こういうことが最近多くなってきているような気がします。＞我も

>>136
FORTRANのCOMMONは知っていますか?
これが現在最大派閥のオーバーレイじゃないかな。

それから大学の図書館で外部の人を入れないところなんてほとんどないよ。
大学の目的に反しているからね。身分証明書があればほとんどOK。
貸し出しはしてくれなくても有料コピーサービスは受けられる。
OPACで在庫図書を検索できるし。
気をつけるのは、学科の図書室は入れないことが多いこと。

>>139
>FORTRANのCOMMONは知っていますか?
>これが現在最大派閥のオーバーレイじゃないかな。
残念ながら、自分はFORTRANは使用したことがありません。

>それから大学の図書館で外部の人を入れないところなんてほとんどないよ。
>大学の目的に反しているからね。身分証明書があればほとんどOK。
>貸し出しはしてくれなくても有料コピーサービスは受けられる。
>OPACで在庫図書を検索できるし。
>気をつけるのは、学科の図書室は入れないことが多いこと。
わざわざ、知らせてくれてすいません。
そこ大学の学生でなければ見れないと思ってました。
後で気づいたんですけど国会図書館を使うっていう手段もあるなと思いました。

現在は、１０章「動的なリンクとロード」を読み終えて、１１章へ突入。
１０章は、中々面白かったです。一番身近な感覚で勉強できますからね。

今日中に終わるか！？

終わったー！！

最後は、Javaでした。ちょこっとしかなかったけど無いよりましか。
全てをざっと読んだ感想は、やはり一筋縄にはいかないものだと思った。
Linker、Loaderを詳細に分かりたい人はこの本だけでなく、
その他の書籍、Web、ソース参照等でカバーしなくてはいけないと思う。

自分もこれからいろいろと調べなくてはならないことが山程あるなと感じた。

LinuxのELFにおいて、シェアードライブラリにスタティックライブラリ
をリンクする事は出来ないのでしょうか？

新規作成分のa.o b.o c.o と既存の流用可能な hoge.a があった
時に、a.o, b.o, c.o, hoge.a から　libHoge.so を作りたいのですが、
どうしても hoge.a をリンクしても libHoge.soにシンボルがリンク
されません。

*.soは、load時にrelocationできるようになっている。
*.aはそうなっていないので、*.soに取り込むことはできない。
arで*.oにばらしてもダメ。

外部シンボルへの参照方法が根本的に違う。

>>143
それはつまり、再配置可能な形態(EXE,DLL)と
オブジェクトファイルの違いということですか？
*.aというのは用はオブジェクトファイルの集合体ですよね。

オブジェクトファイル内のアドレス値は、ファイルイメージ内の
相対アドレスすら決定されていない(リンク時にそれは決定される)から。
逆に(EXE,DLL)は、ローダによって実行時に、各セクションごとメモリ上に
割り当てられるとしても、それはオブジェクトファイル形式にのっとった
操作だから、先頭から何バイト目かは分る。つまり相対アドレスが
決定できる。EXEはプロセス中に一つしか有り得ないから、
DLLとはまた少し事情が違うのかな。

>>143
Linux って *.a から *.so つくるよね？

ld -shared --whole-archive とかって．．．

>>145
gccの-fpicを調べてください。
>>143の最後の一行の意味がわかるかと。

>>146
んー、私が知りたいのは

>143 で
「*.aはそうなっていないので、*.soに取り込むことはできない。arで*.oにばらしてもダメ。」

って言ってるけど、-fpic とか -fPIC でコンパイルしててもダメ(ar で *.o にバラしてもダメ)なの？

なんか -fpic とか -fPIC つきでコンパイルしてたら、ar で *.o にバラしてそれから *.so に取り込めそうだけど．．．

-fpic付きなら問題ない。

ただ、普通は.aだけ作る場合に-fpic付けることはまず無い。

>>148
了解。
確かに *.a だけなら効率のこともあるし -fpic 付けないね。

あー、unixって静的共有ライブラリなんてのがあるのか。納得。

prelinkってどうなの？

prelink
http://lss.eternity.ne.jp/cgi-bin/link/lss_frame.cgi?soft_add.cgi?5065

Mac OS Xだとupdate_prebinding/redo_prebinding

初歩的質問ですみません。
-lhoge とやった際、そのパスに、libhoge.a　と libhoge.so　の両方が
あった場合、どちらがリンクされるんでしょうか？
またlibhoge.aがリンクされる場合は、静的ライブラリの動的リンクって
事になるんでしょうか？

http://www.iecc.com/linker/

arにすると再配置情報が失われでもすんの？
コードがPICでなくともTEXTRELを処理すれば普通に動きそうだけど。

arじゃなくて*.aだった・・・

再配置情報って実際には何？

シンボルの相対位置情報と、
ディスパッチテーブル。

>>156
書き換えたらプロセス間で共有出来なくなるが。

そういやWinのDLLって再配置できるけど、あれってメモリ上では共有されないの？

再配置可能コード、リテラル等、どこに置こうが共有できるがある。

再配置が問題になるシンボルって、そのモジュールで
エクスポートする関数やグローバル変数なんじゃなくて、
モジュール内で参照してる、外部シンボルのことなんだよね？
実際、-fPICや-sharedつけても、外部シンボルを一切参照しない
コードなら、readelf -a foo.oの結果が全く同じだし。

外部シンボルでなくて、
内部のみ有効なシンボルであっても絶対番地参照してはならない。
そうして初めて外部シンボルだけ問題なモジュールとなる。

>>163
オオボケかましてました。自動変数だけのプログラム書いてました（汗
モジュールローカルなstatic変数とそれを用いるプログラム（宣言だけでは
もちろんダメ）を書いたら、-fPICの有無で、ちゃんとreadelf -aにおいて
異なる結果が得られました。何が違うのかはこれからよく見てみますが。

$ cat foo.c
static 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_という名前のエントリが増えてる。

ってな感じですかね。

>>160
> 書き換えたらプロセス間で共有出来なくなるが。
勿論そうだけど、動くには動くでしょ。
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の
シンボル解決ルーチンへジャンプする。

ついでに言うと、i386のPLTの各エントリは最初
１．GOT経由で２．へジャンプするコード
２．dynamic linkerへジャンプするコード
に分かれている。
dynamic linkerは２．から処理を受け取った時に１．で参照した
GOTのエントリを与えられるので、それを書き換える事により
2度目以降の同じ関数の呼び出しはdynamic linkerを通さずに
１．から直接ジャンプする事が出来る。

>勿論そうだけど、動くには動くでしょ。
>PICでない*.aを*.soに取り込めないのは不思議。

これは、オブジェクトファイルのTYPE=PROGBITSの
.textと.dataセクション、TYPE=RELの.rel.textや.rel.dataを
ちょこっと書き換えればPIC形式のオブジェクトファイルに
変換できるだろう、という意味ですか？

>>168
変換しない。
PICがPosition Independent Codeの略なのはオッケー？
コードをPICにする必要があるのは読み取り専用の領域を
プロセス間で使い回す為に再配置を避けたいから。
非PICな(直接絶対番地指定する)コードであっても、
dynamic linkerが読み取り専用領域を一旦書き込み可能にして再配置すれば
プロセス間でメモリ領域の共有が出来ないだけで動作はする筈。

「セクション」って事はlink editorの仕事について言ってるんだろうけど、
link editorはコードが読み取り専用領域のデータの再配置を必要とする場合に
DT_TEXTRELなりDF_TEXTRELなりの情報を載せてdynamic linkerが
正しく処理出来るようにすれば良いんじゃないかな。

>>169
>変換しない。
そうはいっても>>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

>>170
それで何が問題だと思うの？

>>171
アセンブラソースをはりましたが、PICは>>167に書かれている通り、
GOT経由でモジュールローカルな変数(ここではabc)にアクセスしてますよね。
もし仮にNON-PICなモジュールをPICなモジュールとして使おうとすれば、
そのようなGOTへのアクセスルーチンを埋め込み、.rel.textセクションにGOTの
エントリを追加しなくてはならないように思います。

>>172
非PICなコードに必要なのは
movl abc, %eax
のabcの再配置であって、GOT経由のアクセスにする事ではないんじゃ。

>>173
>非PICなコードに必要なのは
>のabcの再配置であって

非PICコードからEXEを作るなら、static変数の
アドレスはリンク時に確定すると思うけど。
.rel.textセクションにエントリが追加されてるのは、
リンク時に.textセクション内のアドレス解決を行うものの
一覧だと思うし。

>>174
EXEではそう。

話がかみあっていないような気がしますが…

>>174
実行するアドレスが一意に決まるなら、それでも問題はないですな。
つーかstaticに限らず全てのアドレス参照がリンク時に解決できなきゃいけない。
あと.rel.textはアドレス解決には関係ない。

例外としてDOSみたいに実行時にアドレスが決定される場合は、ロードした時に
ごにょごにょやるしか無いけど。
今時そんなOSはまずないが。

>あと.rel.textはアドレス解決には関係ない。

.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だと型名などが
微妙に違うと思います。

$objdump -d foo.o　から抜粋
00000000 <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

>>177
型名とマクロはELFの本家ドキュメントのと同じで、
i386なら*BSDでも同じ名前を使ってます。
これ以上何と説明すれば良いやら分からないので、
ゼヒとも仕様を読んでくらはい……。

ELFにはrelocatableとexecutable、sharedの三形式があり、
再配置はlink editorとdynamic linkerの両方が扱うもので
それぞれの意味が違うってのは大丈夫ですよね？
>>169に書いた通り、>>173の再配置というのは
dynamic linkerが行う再配置の事を言っています。

>>179
>型名とマクロは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;

おっとtabがすっとんでしまいました。
CVS-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へのオフセットを計算してますけど。

>>180
そう言えば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を彫り込む、
ってので何が問題だと思います？

誰が誰だか分り難いので番号入れます。

>>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です。

×そもそもGOTは必要ないですよね？
○static変数の参照においてはそもそもGOTは必要ないですよね？

>>183
> 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は必要ないですよね？
動けば良いという発想なら必要ありません。

>>185
>> EXEと違い、DYNにおいてはモジュールローカルなstatic変数のアドレスが分らない
>dynamic linkerは一意に決められますし、決められないと話になりません。
これはリンク時に限定した話です。

>dynamic linkerはsharedを配置するアドレスをプロセス毎に一意に決められますが、
>普通は利用するプロセス毎に違うアドレスを使います。
>>>170で言うabcのアドレスを特定のプロセスでの絶対番地に変換＝再配置してしまうと、
>同じコードを別のプロセスが利用する事が出来なくなります。
・・・
>コードを共有するのにはmmap()等を使います。
おぼろげながらやっと理解できました。straceでローダーの動作を確認してみました。


そこでですが、やはり理解できないのは、
>> コンパイルフェーズで確定したプログラムロジックを後から修正
>abcの再配置情報をリンカが作成した上でDT_TEXTRELってフラグをsharedに付けるだけです。
>PICに変換する必要は無いのでロジックはコンパイル以降変わりません。
上で見た通り、dynamic linkerはメモリ上にプログラムコードを配置する時に
コードに埋め込まれたアドレス値を書き換えることは出来ないわけですよね？

[[[ foo.o ]]]
00000000 <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がアドレス値を確定しても、プログラム領域を書き変えるわけにはいかない。

>>186
> 上で見た通り、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だと思います。

>>dynamic linkerはメモリ上にプログラムコードを配置する時に
>> コードに埋め込まれたアドレス値を書き換えることは出来ないわけですよね？
>いいえ、出来ます。
>例えば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を理解できたら、そのうち調べてみたいです。

>>185にメモリが無駄になるって書いてあるじゃん。
ページごとにCopyが起きるからね。

実際、関数呼び出しがあるページがコピーされたら、
プログラムの領域はほぼ全部コピーされちゃうんじゃない?

>>190
＞>>185にメモリが無駄になるって書いてあるじゃん。
それは分っています。ローダーがページ境界に収まるように
DYN内の.non-pic.text(仮)セクションをメモリ内にコピー＆アドレス値を
上書きすることでは、それ程無駄になら気も。気のせいかな。。。
ただ、CoWとは言っても、実行が開始される前のdynamic linkerが
コード内のアドレス値を書き換える時点において、ページが割り当てられて
しまうんですね。当たり前ですが。そのコードが実行されるかどうかに関係なく。
最近のOSならばページフォルトを利用したVMMによるファイルの遅延ロードは
どれも実装されていると思いますので、下手したら、静的リンクよりも
効率の悪いものになるかも？！

>実際、関数呼び出しがあるページがコピーされたら、
>プログラムの領域はほぼ全部コピーされちゃうんじゃない?
これはどういう意味ですか？できればもう少し詳しくお願いします。
先にPICなセクションを再配置しておいてから、non-PICなセクションを
処理すれば、あまり問題がないような。
DYNにnon-PICなコードを含めるのならば、セクションを別にする必要が
あるだろうと思います。

不勉強なのに適当な印象の話ばかり書き込みました。しばらくELFと
dynamic linkerについて調べてきます。

>>189
ちょうどcygwinでi386のelfを吐けるクロスコンパイラをビルドしたところだったので
試しにやってみたらnon-PICなrelocatableからsharedを作れました。
# ていうか最初に試せ　＞俺
>>142の人がどういう手順と環境で出来なかったのか気になります……。

>>192
おお、それはGOODニュースですね！
で、できればリンカオプションを教えてください・・・orz

ああ、これでいいのか。
$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

なんか今まであれこれ憶測並べてたのが恥かしくなってきた。
もう寝る。。

>>191
> DYNにnon-PICなコードを含めるのならば、セクションを別にする必要がある
まるっきり勘で言いますけど、普通別にしないような気がします。
まあ勘なんでなるたけ突っ込まないで下さい。
あと細かい点ですが、実行時の視点で見るのはセクションでなくセグメントです。
ELFの場合この用語は混同しない方が良いです。

>>194
すんません、普段ELFを作れる環境を使わなかったんで……。

Sunのサイトで公開されてるSolarisのマニュアルにリンカに関する物があって、
それにELFの仕様の邦訳っぽい物も含まれてます。
所々微妙な訳もありますけど、一応メンテナンスはされてるようなんで
英語がとっつき辛い場合はそれも参考にすると良いかもしれません。

保守

誰か呼んだか？

>>197
それはGTO。

cygwinのldでブートセクタを生成しようとしてるんですが

ld -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 */
}

>>199
boot.oはどうやって生成した?

>>200
Makefileの内容です。

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

boot.oがELFか、リンカスクリプトがELF前提か
どっちかだと思ったんだよな。
ldのメッセージは前者っぽいんだけど
gccがcygwinネイティブなら後者かなー。
今携帯からなんでPEのリファレンスがねーのよ。

お忙しい中ありがとうございます。

ばいなりエディタでboot.oを各環境とも開いてみたらLinux側は先頭に
.ELF
があって、Cygwin側の先頭は
L<
text
って感じでした。
自分ではこれが何を意味しているか分からないですが参考までに。
よろしくお願いいたします。

えー、まだ出先でリファレンスがないので、予想だけ書いとくね
リンカスクリプトのboot.lsが元のオブジェクトファイルの中から
.textセクションとか.rodataセクションを抜きだして
(セクション構造のない)ベタなbinaryにしようとしてるわけだけど、
このセクション構造がELFにあってPEにないもので、
cygwinで作ったバイナリがPEなもんだから
ldが処理できませーんとかになってんじゃないのかなみたいな

ld -v -T img/boot.ls -o img/boot img/boot.o
して詳細メッセージ出したのをはってもらえない?

以下のようになりました

$ 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.

試しにに-Vにしてみたら。

$ 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.

となりました。

http://my.execpc.com/~geezer/osd/exec/
http://my.execpc.com/~geezer/embed/bugs.htm#mingbug

自分のプログラムでexe作りたいんですが、
超簡単なmsvcrtの関数使うサンプルとかないですかね？

そういや市販コンパイラが作るDLL関数の呼び出しコードって
インポートテーブルから
call DWORD ptr[import_table_address]
のようなことしてるけど、別に
mov eax, procedure_addres
call eax
としてもいいよなあ。
なんで１段参照増やしてんの？
インポートテーブル分無駄じゃない？

あ、全部のRVA持つよかコスト安いのか。
なるほどねー。

PEフォーマットの.idataのインポートセクションについて質問です。
の各DLL関数名の前に付いている、
「ヒント」の値って、何を入れるんでしょうか？

意味がまるでわからないです。

適当でいいんじゃね？
どうせ名前で調べるし

おそらく、DLLに登録された関数の序数(.DEFで登録する番号？)だと思いますが、
こんなのどうやって知るのでしょうか。
参照する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にしてやったらうまくいきました。

このヒントは、パフォーマンス上の理由でしかないのでしょうか？

>>212
そうですね。
実験してとりあえず無視して問題なかったので、
しばらく放置プレイしときます。

それとも、Kernel32.dllとかの基本的なDLLについては、
リンカであらかじめ序数を控えておいた方が良いのかな。

DLLの関数を全部列挙するなんてAPIないですよね・・・。
objdump.exeで取ってくるしかない？

>>215
同じことだけど PE 解析ルーチンを書けばいい。

セクションの場所とか位置変えるの面倒っすね。
それとexe自体よりスタートアップ作るのが面倒すぎる。
Win32APIしか使わないなら話は簡単だけど、
Cランタイム使えないとあんま意味ないんだよなあ。
とりあえずmsvcrt.dllを安全に使えるレベルとか考えてたけど
無理な気がしてきた。
mingwやlccwin解析すりゃいいんだろうけどね。
すげー遠い。
素直に既成のリンカへ.obj渡す事考えた方が早いかも。

Interface 12月号から、「リンカを100%使いこなそう!」
という連載が始まったよ。

今回は13Pで、主に用語など基礎知識の説明でした。
次回はELF形式のお話みたいなんで期待。

>210
Interfaceのこの手の記事は使えそうで使えないからなあ。
ELF形式なんてGNU系の資料いっぱいあるからPEやって欲しいのだが。
PEやる予定あるのかな。
無かったら笑えるがな。

>>218

PE ｲﾗﾈ

age

libcに存在するシンボルを自分のプログラム内で定義して
実行ファイルを作成した場合、必ずどっちが優先されるとか
ってあるんでしょうか？

interpositioningでぐぐれ

オタにはまぁ買っといても損はないって感じかな
内容上重複というか同じような事書いてる部分は多いかもしれないが
読んで楽しめるとは思う
ちなみにLinker"s"
sが付く、これ重要
どうでもいいが漏れの近くの書店ではHTMLの分類の所に
隣近所はHTMLとかホームページとか
田舎の書店のアルバイトじゃ分類タイトルみただけじゃそうなるだろうなぁ

ぶっちゃけ、「Linkers & Loaders」のような本が少なすぎる。

まぁ資料WEBにあるし、マイナーなの乗せてたりとか表っぽいところとか
オタ本の分類だろうし
少なすぎるというかそもそもたくさんある類いの本じゃないよね

オタ本って．．．確かにそうなんだけど。
もっと美しく言うと専門書籍って言わない？(萌え本みたいな印象もあるし)

つ〜か、あえてこういう分野において本を出版する事が、専門書の価値として生きるんだけどなぁ。
みんな(出版社とか)は、わかって無いよなぁ。チャンスなのに。

>>228
萌え本ってなんですか？

>>230
http://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

>>226
×ぶっちゃけ、「Linkers & Loaders」のような本が少なすぎる。
○ぶっちゃけ、「Linkers & Loaders」のような本を読む人が少なすぎる。

リンカー＆ローダーとかPICとか*.a *.soを詳細に解説した本って売ってない？

>>219
PEフォーマットってCOFFフォーマットの別名だよ。

>>233
L&LかInterfaceの連載くらいしか見たことない。

>>234
PEとCOFFは同一ではないから、別名というのは違う。
COFFを拡張したのがPE。

COFFとPEは結構用語が変わってるから拡張というよりM$ローカライズな希ガス

プログラムを書くとリンカーが勝手にリンクしているcrt0.oを解説したドキュメントってどこかに無いですか？
いったいこれは何なのか。
私の書いたmain以外のstartとかendとかいったシンボル名は何なのかと。

>>237
ソース見たほうが早いよね

>>238
ソースがあるといいね。

>>237
ただの entry point でしょ。

>>239
何でソースが無いと思ったの?

>>240
crt0.oなんて名前はありきたりで環境が分からないから。

(´-`).｡ｏO(結局どこを見ればいいんだろう……)

>>237
いっぱいあるよ

>>242
crt0ってのは（名前からすると）Cランタイムライブラリを初期化するためのコードで、
Cランタイムライブラリに依存するもの（≒Cコンパイラに依存するもの）。
ライブラリ（コンパイラ）のマニュアルに書いてあるかもしれないし、
コンパイラセットにソースコードが付いてることもある（少なくともMSVCには付いてる）。

つか、ググれば腐る程出て来るんだよ

少なくともcrt0.oならMSVCではないな。

.oならunix系かね。いずれにしても環境も明記してないんじゃ、言及できるのはこの程度か。

(´-`).｡ｏO(Linux(FedoraCore1)でgccなんだな…ググっても出てこないんだな…)

gccならソース読めで終わり。

*argv[]を準備したり。

(´-`).｡ｏO(その読むべきソースの名前がわからないんだな…解説資料もあるとうれしい）

gcc-3.4.X/gcc/{Makefile.in,unwind*,config/*}

次はソースの内容を解説してくれ、か？

スレ違いじゃねぇの？
一応、適当なリンクを貼っておくが。
http://pc8.2ch.net/test/read.cgi/tech/1058134693/726-

(´-`).｡ｏO(所詮わらはわらか…）

五月蠅い、無能が喋るな。
無能は震えながらではなく、藁のように氏ぬのだ。

>>256
そういうの恥ずかしいから辞めようよ

>>257
【鉄則】アホはスルー

【結論】 >>258=アホ

>>20
リンカからコンパイラ、アセンブラまで作ったが
さすがにOSはアホらしいな。

WINNTやWINNT\System32の下のDLLはImageBaseが指定されてるものが多いけど、
もしかしてWindows付属のDLLって全部アドレス空間のどこにマップされるか、
最初から全部決まってるの？

その方が実行が早い

べーしっ君が買えなくて、しかたなく自作したことはある

>>264ｹﾞｯﾄずざー！！
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

>>262
それはもちろんそうなんだけど、仮想アドレス空間の無駄使いじゃない？

>>265
ページは4kバイト単位なのでそうでもない
それに指定されたページにロードできなかった場合でも違う場所に割り当てられる

>>265
世の中の大半の用途では、物理メモリはともかく
アドレス空間ケチるほどメモリ使わないので問題ない。

とか言ってた時期がLinuxにもありました。結局それじゃ持たなくなってELFになったね。

>>268
くやしく

>>266
＞それに指定されたページにロードできなかった場合でも違う場所に割り当てられる

え、じゃあ例えば、俺の使ってるWindowsのNTDLL.DLL、
ImageBaseは0x77f80000という値になってるけど、これは
別の場所に再配置することも可能なの？

>>268
ELFへの移行は
・共有ライブラリが作りやすい
・動的リンクがやりやすい
・クロス開発がやりやすい
・C++対応（コンストラクタとデストラクタ）
が主な理由。

64bit対応ってのは（当時と今は）あまり重要ではない。
未来は知らんが。

>>270
DLLは基本的に再配置するものなので、必ず再配置セクションを持つ。
NTDLL.DLLも再配置セクションがあるので（dumpbinで覗いてみ）、
必要なら再配置できる。

>>272
それだとImageBaseを固定するメリットってあんまりなくない？

>>273
適当なアドレスに固定してるんじゃなくて、
一通りメモリに読み込んで再配置完了したのと同等のアドレスにしてある。

アプリ起動のたびにほぼ必ず読み込まれるシステム系のDLLを
毎回再配置しないで済む分、起動が速くなる。

ビットマップをリンクしたいんだけど、どうしたらいいのか
とりあえず、ヒントくれ

>>275
objcpy

意外と知られていないが
Cygwin/Mingwが吐く relocatable object file は
MS環境でもリンクできる。

なので objcopy 最強。

objcopyってsupported targetsにあればアーキテクチャを越えたバイナリ変換ってできる？
例えば
　elf32-i386 -> elf32-powerpcle
とか。

>>278
できたと思った。昔configureして
ぜんぶ入りのobjcopyを作ったことがある

>>279
できないお　　＞_＜

$ 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

だめかー。やっぱり一旦binaryを経由させないと無理か。

保守！上げたら怒りますか？
１時間以内に返答が無かったら賛同してくれるものと見なす。

別に怒りはしないが、age るならそれなりのネタを用意して欲しい物だな。
まさか、単なる保守 age じゃないよね??

うわ。まだ見てる人がいただなんて！
ネタはないですね。そろそろ落ちるんじゃないかと思った。
しいて言えば本購入予定です。ハイ。

保守。

保守。

.laと.soの違いって何ですか?

.a → .la
.so → .lo
というlibtool版か。

.soはあるのに、.laがなくなると起動しなくなるものがあるって事は、
.laをdlopenしているアプリがあるのかな。

がーん、.laって共有ライブラリの情報ファイルなんだな。

>>287
そーそー、textファイルだから、開けてびっくりするよな。
libディレに、んなもんイッパイ入れんな！と、最初思ったよ。

PEの.rsrcセクション
わかるやつおらんかね？
さっぱり意味のわかる資料がない

自分でリソース追加したいんだが

binutils自ら追っかけてみれば?