Linker && Loader
■ このスレッドは過去ログ倉庫に格納されています
0001さとし ◆k4PcAe16
NGNG難しいような気がするんですが。。。
僕もリンカとローダを作れるようになれますか？
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を
毎回再配置しないで済む分、起動が速くなる。
■ このスレッドは過去ログ倉庫に格納されています