私はいつも興味がありました
- プロセスはメモリ内でどの程度正確に見えますか？
- その中の異なるセグメント（パーツ）は何ですか？
- プログラム（ディスク上）とプロセス（メモリ内）はどの程度正確に関連していますか？
私の前の質問：実行可能プログラム（プロセス）のメモリレイアウトに関する詳細
私の探求において、私はついに答えを見つけました。私のクエリのほとんどをクリアしたこの優れた記事を見つけました：http ：//www.linuxforums.org/articles/understanding-elf-using-readelf-and-objdump_125.html
上記の記事では、作成者はプロセスのさまざまなセグメント（LINUX）を取得する方法を示し、対応するELFファイルと比較します。私はここでこのセクションを引用しています：
プロセスセグメントの実際のレイアウトを知りたいですか？/ proc//mapsファイルを使用してそれを明らかにすることができます。観察したいプロセスのPIDです。先に進む前に、ここで小さな問題があります。テストプログラムは非常に高速に実行されるため、関連する/procエントリをダンプする前に終了します。これを解決するためにgdbを使用します。return（）を呼び出す前にsleep（）を挿入するなど、別のトリックを使用できます。
コンソール（またはxtermなどのターミナルエミュレーター）では、次のようにします。
$ gdb test
(gdb) b main
Breakpoint 1 at 0x8048376
(gdb) r
Breakpoint 1, 0x08048376 in main ()
ここを押したまま、別のコンソールを開いて、プログラム「test」のPIDを見つけます。簡単な方法が必要な場合は、次のように入力します。
$ cat /proc/`pgrep test`/maps
以下のような出力が表示されます（異なる出力が得られる場合があります）。
[1] 0039d000-003b2000 r-xp 00000000 16:41 1080084 /lib/ld-2.3.3.so
[2] 003b2000-003b3000 r--p 00014000 16:41 1080084 /lib/ld-2.3.3.so
[3] 003b3000-003b4000 rw-p 00015000 16:41 1080084 /lib/ld-2.3.3.so
[4] 003b6000-004cb000 r-xp 00000000 16:41 1080085 /lib/tls/libc-2.3.3.so
[5] 004cb000-004cd000 r--p 00115000 16:41 1080085 /lib/tls/libc-2.3.3.so
[6] 004cd000-004cf000 rw-p 00117000 16:41 1080085 /lib/tls/libc-2.3.3.so
[7] 004cf000-004d1000 rw-p 004cf000 00:00 0
[8] 08048000-08049000 r-xp 00000000 16:06 66970 /tmp/test
[9] 08049000-0804a000 rw-p 00000000 16:06 66970 /tmp/test
[10] b7fec000-b7fed000 rw-p b7fec000 00:00 0
[11] bffeb000-c0000000 rw-p bffeb000 00:00 0
[12] ffffe000-fffff000 ---p 00000000 00:00 0
注：参照として各行に番号を追加します。
gdbに戻り、次のように入力します。
（gdb）q
したがって、合計で12のセグメント（仮想メモリ領域--VMAとも呼ばれます）が表示されます。
しかし、私はWindowsプロセスとPEファイル形式について知りたいです。
- Windowsで実行中のプロセスのレイアウト（セグメント）を取得するためのツールはありますか？
- このテーマについてさらに学ぶための他の良いリソースはありますか？
編集：
PEファイルsectionsとVAの間のマッピングを示す良い記事はありますsegmentsか？
.jpg){kind=link}