Linker && Loader

>>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自ら追っかけてみれば?