トップページ⇒tech
292コメント106KB

Linker && Loader

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

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

不勉強なのに適当な印象の話ばかり書き込みました。しばらくELFと
dynamic linkerについて調べてきます。
0192156NGNG
>>189
ちょうどcygwinでi386のelfを吐けるクロスコンパイラをビルドしたところだったので
試しにやってみたらnon-PICなrelocatableからsharedを作れました。
# ていうか最初に試せ　＞俺
>>142の人がどういう手順と環境で出来なかったのか気になります……。
0193デフォルトの名無しさんNGNG
>>192
おお、それはGOODニュースですね！
で、できればリンカオプションを教えてください・・・orz
0194162NGNG
ああ、これでいいのか。
$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

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

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

Sunのサイトで公開されてるSolarisのマニュアルにリンカに関する物があって、
それにELFの仕様の邦訳っぽい物も含まれてます。
所々微妙な訳もありますけど、一応メンテナンスはされてるようなんで
英語がとっつき辛い場合はそれも参考にすると良いかもしれません。
0196デフォルトの名無しさんNGNG
保守
0197鬼塚先生NGNG
誰か呼んだか？
0198デフォルトの名無しさんNGNG
>>197
それはGTO。
0199デフォルトの名無しさんNGNG
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 */
}
0200デフォルトの名無しさんNGNG
>>199
boot.oはどうやって生成した?
0201199NGNG
>>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
0202デフォルトの名無しさんNGNG
boot.oがELFか、リンカスクリプトがELF前提か
どっちかだと思ったんだよな。
ldのメッセージは前者っぽいんだけど
gccがcygwinネイティブなら後者かなー。
今携帯からなんでPEのリファレンスがねーのよ。
0203199NGNG
お忙しい中ありがとうございます。

ばいなりエディタでboot.oを各環境とも開いてみたらLinux側は先頭に
.ELF
があって、Cygwin側の先頭は
L<
text
って感じでした。
自分ではこれが何を意味しているか分からないですが参考までに。
よろしくお願いいたします。
0204デフォルトの名無しさんNGNG
えー、まだ出先でリファレンスがないので、予想だけ書いとくね
リンカスクリプトのboot.lsが元のオブジェクトファイルの中から
.textセクションとか.rodataセクションを抜きだして
(セクション構造のない)ベタなbinaryにしようとしてるわけだけど、
このセクション構造がELFにあってPEにないもので、
cygwinで作ったバイナリがPEなもんだから
ldが処理できませーんとかになってんじゃないのかなみたいな
0205デフォルトの名無しさんNGNG
ld -v -T img/boot.ls -o img/boot img/boot.o
して詳細メッセージ出したのをはってもらえない?
0206199NGNG
以下のようになりました

$ 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.
0207199NGNG
試しにに-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.

となりました。
0208デフォルトの名無しさんNGNG
http://my.execpc.com/~geezer/osd/exec/
http://my.execpc.com/~geezer/embed/bugs.htm#mingbug
0209デフォルトの名無しさんNGNG
自分のプログラムでexe作りたいんですが、
超簡単なmsvcrtの関数使うサンプルとかないですかね？

そういや市販コンパイラが作るDLL関数の呼び出しコードって
インポートテーブルから
call DWORD ptr[import_table_address]
のようなことしてるけど、別に
mov eax, procedure_addres
call eax
としてもいいよなあ。
なんで１段参照増やしてんの？
インポートテーブル分無駄じゃない？
0210デフォルトの名無しさんNGNG
あ、全部のRVA持つよかコスト安いのか。
なるほどねー。
0211デフォルトの名無しさんNGNG
PEフォーマットの.idataのインポートセクションについて質問です。
の各DLL関数名の前に付いている、
「ヒント」の値って、何を入れるんでしょうか？

意味がまるでわからないです。
0212デフォルトの名無しさんNGNG
適当でいいんじゃね？
どうせ名前で調べるし
0213デフォルトの名無しさんNGNG
おそらく、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にしてやったらうまくいきました。

このヒントは、パフォーマンス上の理由でしかないのでしょうか？
0214デフォルトの名無しさんNGNG
>>212
そうですね。
実験してとりあえず無視して問題なかったので、
しばらく放置プレイしときます。
0215デフォルトの名無しさんNGNG
それとも、Kernel32.dllとかの基本的なDLLについては、
リンカであらかじめ序数を控えておいた方が良いのかな。

DLLの関数を全部列挙するなんてAPIないですよね・・・。
objdump.exeで取ってくるしかない？
0216デフォルトの名無しさんNGNG
>>215
同じことだけど PE 解析ルーチンを書けばいい。
0217デフォルトの名無しさんNGNG
セクションの場所とか位置変えるの面倒っすね。
それとexe自体よりスタートアップ作るのが面倒すぎる。
Win32APIしか使わないなら話は簡単だけど、
Cランタイム使えないとあんま意味ないんだよなあ。
とりあえずmsvcrt.dllを安全に使えるレベルとか考えてたけど
無理な気がしてきた。
mingwやlccwin解析すりゃいいんだろうけどね。
すげー遠い。
素直に既成のリンカへ.obj渡す事考えた方が早いかも。
0218デフォルトの名無しさんNGNG
Interface 12月号から、「リンカを100%使いこなそう!」
という連載が始まったよ。

今回は13Pで、主に用語など基礎知識の説明でした。
次回はELF形式のお話みたいなんで期待。
0219デフォルトの名無しさんNGNG
>210
Interfaceのこの手の記事は使えそうで使えないからなあ。
ELF形式なんてGNU系の資料いっぱいあるからPEやって欲しいのだが。
PEやる予定あるのかな。
無かったら笑えるがな。
0220デフォルトの名無しさんNGNG
>>218
0221デフォルトの名無しさんNGNG
PE ｲﾗﾈ
0222デフォルトの名無しさん05/02/05 10:26:28
age
0223デフォルトの名無しさん05/02/06 03:09:02
libcに存在するシンボルを自分のプログラム内で定義して
実行ファイルを作成した場合、必ずどっちが優先されるとか
ってあるんでしょうか？
0224Rubyist!05/02/06 03:12:03
interpositioningでぐぐれ
0225デフォルトの名無しさん05/02/14 14:21:01
オタにはまぁ買っといても損はないって感じかな
内容上重複というか同じような事書いてる部分は多いかもしれないが
読んで楽しめるとは思う
ちなみにLinker"s"
sが付く、これ重要
どうでもいいが漏れの近くの書店ではHTMLの分類の所に
隣近所はHTMLとかホームページとか
田舎の書店のアルバイトじゃ分類タイトルみただけじゃそうなるだろうなぁ
0226デフォルトの名無しさん05/03/05 05:38:08
ぶっちゃけ、「Linkers & Loaders」のような本が少なすぎる。
0227デフォルトの名無しさん05/03/05 05:49:40
まぁ資料WEBにあるし、マイナーなの乗せてたりとか表っぽいところとか
オタ本の分類だろうし
少なすぎるというかそもそもたくさんある類いの本じゃないよね
022822605/03/05 06:05:41
オタ本って．．．確かにそうなんだけど。
もっと美しく言うと専門書籍って言わない？(萌え本みたいな印象もあるし)
022922605/03/05 06:21:23
つ〜か、あえてこういう分野において本を出版する事が、専門書の価値として生きるんだけどなぁ。
みんな(出版社とか)は、わかって無いよなぁ。チャンスなのに。
0230デフォルトの名無しさん05/03/05 06:42:57
>>228
萌え本ってなんですか？
0231デフォルトの名無しさん05/03/05 08:36:54
>>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
0232デフォルトの名無しさん2005/05/26(木) 21:34:03
>>226
×ぶっちゃけ、「Linkers & Loaders」のような本が少なすぎる。
○ぶっちゃけ、「Linkers & Loaders」のような本を読む人が少なすぎる。
0233デフォルトの名無しさん2005/05/26(木) 22:02:20
リンカー＆ローダーとかPICとか*.a *.soを詳細に解説した本って売ってない？
0234本田& ◆xOS3wf.pJg 2005/05/27(金) 01:11:58
>>219
PEフォーマットってCOFFフォーマットの別名だよ。
0235デフォルトの名無しさん2005/05/27(金) 19:17:49
>>233
L&LかInterfaceの連載くらいしか見たことない。

>>234
PEとCOFFは同一ではないから、別名というのは違う。
COFFを拡張したのがPE。
0236デフォルトの名無しさん2005/05/28(土) 22:18:45
COFFとPEは結構用語が変わってるから拡張というよりM$ローカライズな希ガス
0237デフォルトの名無しさん2005/06/25(土) 21:26:29
プログラムを書くとリンカーが勝手にリンクしているcrt0.oを解説したドキュメントってどこかに無いですか？
いったいこれは何なのか。
私の書いたmain以外のstartとかendとかいったシンボル名は何なのかと。
0238デフォルトの名無しさん2005/06/25(土) 23:22:56
>>237
ソース見たほうが早いよね
0239デフォルトの名無しさん2005/06/25(土) 23:50:58
>>238
ソースがあるといいね。
0240デフォルトの名無しさん2005/06/26(日) 00:27:02
>>237
ただの entry point でしょ。

>>239
何でソースが無いと思ったの?
02412392005/06/26(日) 01:04:27
>>240
crt0.oなんて名前はありきたりで環境が分からないから。
02422372005/06/26(日) 09:42:43
(´-`).｡ｏO(結局どこを見ればいいんだろう……)
0243デフォルトの名無しさん2005/06/26(日) 15:20:31
>>237
いっぱいあるよ
0244デフォルトの名無しさん2005/06/26(日) 15:32:33
>>242
crt0ってのは（名前からすると）Cランタイムライブラリを初期化するためのコードで、
Cランタイムライブラリに依存するもの（≒Cコンパイラに依存するもの）。
ライブラリ（コンパイラ）のマニュアルに書いてあるかもしれないし、
コンパイラセットにソースコードが付いてることもある（少なくともMSVCには付いてる）。
0245デフォルトの名無しさん2005/06/26(日) 15:36:41
つか、ググれば腐る程出て来るんだよ
0246デフォルトの名無しさん2005/06/26(日) 16:27:58
少なくともcrt0.oならMSVCではないな。
0247デフォルトの名無しさん2005/06/26(日) 16:55:09
.oならunix系かね。いずれにしても環境も明記してないんじゃ、言及できるのはこの程度か。
02482372005/06/26(日) 23:49:07
(´-`).｡ｏO(Linux(FedoraCore1)でgccなんだな…ググっても出てこないんだな…)
0249デフォルトの名無しさん2005/06/27(月) 00:32:08
gccならソース読めで終わり。
0250デフォルトの名無しさん2005/06/27(月) 08:51:19
*argv[]を準備したり。
02512372005/06/27(月) 22:21:58
(´-`).｡ｏO(その読むべきソースの名前がわからないんだな…解説資料もあるとうれしい）
0252デフォルトの名無しさん2005/06/27(月) 23:35:47
gcc-3.4.X/gcc/{Makefile.in,unwind*,config/*}
0253デフォルトの名無しさん2005/06/28(火) 01:07:57
次はソースの内容を解説してくれ、か？
0254デフォルトの名無しさん2005/06/28(火) 17:46:07
スレ違いじゃねぇの？
一応、適当なリンクを貼っておくが。
http://pc8.2ch.net/test/read.cgi/tech/1058134693/726-
02552372005/07/02(土) 19:27:18
(´-`).｡ｏO(所詮わらはわらか…）
0256デフォルトの名無しさん2005/07/03(日) 04:05:18
五月蠅い、無能が喋るな。
無能は震えながらではなく、藁のように氏ぬのだ。
0257デフォルトの名無しさん2005/07/03(日) 14:35:28
>>256
そういうの恥ずかしいから辞めようよ
0258デフォルトの名無しさん2005/07/03(日) 18:39:57
>>257
【鉄則】アホはスルー
0259デフォルトの名無しさん2005/07/04(月) 15:02:23
【結論】 >>258=アホ
0260デフォルトの名無しさん2005/09/18(日) 16:41:50
>>20
リンカからコンパイラ、アセンブラまで作ったが
さすがにOSはアホらしいな。
0261デフォルトの名無しさん2005/11/24(木) 04:18:36
WINNTやWINNT\System32の下のDLLはImageBaseが指定されてるものが多いけど、
もしかしてWindows付属のDLLって全部アドレス空間のどこにマップされるか、
最初から全部決まってるの？
0262デフォルトの名無しさん2005/11/24(木) 06:46:41
その方が実行が早い
0263デフォルトの名無しさん2005/11/24(木) 10:53:10
べーしっ君が買えなくて、しかたなく自作したことはある
0264デフォルトの名無しさん2005/11/24(木) 16:38:48
>>264ｹﾞｯﾄずざー！！
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ
0265デフォルトの名無しさん2005/11/24(木) 17:15:11
>>262
それはもちろんそうなんだけど、仮想アドレス空間の無駄使いじゃない？
0266デフォルトの名無しさん2005/11/24(木) 17:42:10
>>265
ページは4kバイト単位なのでそうでもない
それに指定されたページにロードできなかった場合でも違う場所に割り当てられる
0267デフォルトの名無しさん2005/11/24(木) 23:06:29
>>265
世の中の大半の用途では、物理メモリはともかく
アドレス空間ケチるほどメモリ使わないので問題ない。
0268デフォルトの名無しさん2005/11/24(木) 23:12:05
とか言ってた時期がLinuxにもありました。結局それじゃ持たなくなってELFになったね。
0269デフォルトの名無しさん2005/11/24(木) 23:16:14
>>268
くやしく
0270デフォルトの名無しさん2005/11/24(木) 23:56:56
>>266
＞それに指定されたページにロードできなかった場合でも違う場所に割り当てられる

え、じゃあ例えば、俺の使ってるWindowsのNTDLL.DLL、
ImageBaseは0x77f80000という値になってるけど、これは
別の場所に再配置することも可能なの？
0271デフォルトの名無しさん2005/11/24(木) 23:57:00
>>268
ELFへの移行は
・共有ライブラリが作りやすい
・動的リンクがやりやすい
・クロス開発がやりやすい
・C++対応（コンストラクタとデストラクタ）
が主な理由。

64bit対応ってのは（当時と今は）あまり重要ではない。
未来は知らんが。
0272デフォルトの名無しさん2005/11/25(金) 00:07:06
>>270
DLLは基本的に再配置するものなので、必ず再配置セクションを持つ。
NTDLL.DLLも再配置セクションがあるので（dumpbinで覗いてみ）、
必要なら再配置できる。
0273デフォルトの名無しさん2005/11/25(金) 01:32:46
>>272
それだとImageBaseを固定するメリットってあんまりなくない？
0274デフォルトの名無しさん2005/11/25(金) 02:31:37
>>273
適当なアドレスに固定してるんじゃなくて、
一通りメモリに読み込んで再配置完了したのと同等のアドレスにしてある。

アプリ起動のたびにほぼ必ず読み込まれるシステム系のDLLを
毎回再配置しないで済む分、起動が速くなる。
0275デフォルトの名無しさん2005/12/21(水) 10:46:27
ビットマップをリンクしたいんだけど、どうしたらいいのか
とりあえず、ヒントくれ
0276デフォルトの名無しさん2005/12/21(水) 13:35:48
>>275
objcpy
0277デフォルトの名無しさん2005/12/25(日) 19:40:34
意外と知られていないが
Cygwin/Mingwが吐く relocatable object file は
MS環境でもリンクできる。

なので objcopy 最強。
0278デフォルトの名無しさん2005/12/25(日) 23:37:14
objcopyってsupported targetsにあればアーキテクチャを越えたバイナリ変換ってできる？
例えば
　elf32-i386 -> elf32-powerpcle
とか。
0279デフォルトの名無しさん2005/12/26(月) 00:50:29
>>278
できたと思った。昔configureして
ぜんぶ入りのobjcopyを作ったことがある
02802782005/12/26(月) 16:09:38
>>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
0281デフォルトの名無しさん2005/12/27(火) 20:48:33
だめかー。やっぱり一旦binaryを経由させないと無理か。
0282デフォルトの名無しさん2006/02/17(金) 13:52:54
保守！上げたら怒りますか？
１時間以内に返答が無かったら賛同してくれるものと見なす。
0283デフォルトの名無しさん2006/02/17(金) 14:14:27
別に怒りはしないが、age るならそれなりのネタを用意して欲しい物だな。
まさか、単なる保守 age じゃないよね??
0284デフォルトの名無しさん2006/02/17(金) 14:17:11
うわ。まだ見てる人がいただなんて！
ネタはないですね。そろそろ落ちるんじゃないかと思った。
しいて言えば本購入予定です。ハイ。
0285デフォルトの名無しさん2006/02/20(月) 11:25:05
保守。
0286デフォルトの名無しさん2006/02/21(火) 10:47:36
保守。
0287デフォルトの名無しさん2006/04/25(火) 10:08:26
.laと.soの違いって何ですか?
02882872006/04/25(火) 13:37:56
.a → .la
.so → .lo
というlibtool版か。

.soはあるのに、.laがなくなると起動しなくなるものがあるって事は、
.laをdlopenしているアプリがあるのかな。
02892872006/04/25(火) 16:17:41
がーん、.laって共有ライブラリの情報ファイルなんだな。
0290デフォルトの名無しさん2006/04/28(金) 22:50:10
>>287
そーそー、textファイルだから、開けてびっくりするよな。
libディレに、んなもんイッパイ入れんな！と、最初思ったよ。
■ このスレッドは過去ログ倉庫に格納されています