Ý nghĩa của đầu ra của pmap


12

Tôi đã viết main.cbằng Linux:

int main()
{
  while (1){}
}

Khi tôi biên dịch và khởi động nó, tôi có thể pmap:

# pmap 28578
28578:   ./a.out
0000000000400000      4K r-x--  /root/a.out
0000000000600000      4K r----  /root/a.out
0000000000601000      4K rw---  /root/a.out
00007f87c16c2000   1524K r-x--  /lib/libc-2.11.1.so
00007f87c183f000   2044K -----  /lib/libc-2.11.1.so
00007f87c1a3e000     16K r----  /lib/libc-2.11.1.so
00007f87c1a42000      4K rw---  /lib/libc-2.11.1.so
00007f87c1a43000     20K rw---    [ anon ]
00007f87c1a48000    128K r-x--  /lib/ld-2.11.1.so
00007f87c1c55000     12K rw---    [ anon ]
00007f87c1c65000      8K rw---    [ anon ]
00007f87c1c67000      4K r----  /lib/ld-2.11.1.so
00007f87c1c68000      4K rw---  /lib/ld-2.11.1.so
00007f87c1c69000      4K rw---    [ anon ]
00007fff19b82000     84K rw---    [ stack ]
00007fff19bfe000      8K r-x--    [ anon ]
ffffffffff600000      4K r-x--    [ anon ]
 total             3876K

tổng (3876) chia cho K bằng VIRTcột trong đầu ra của top. Bây giờ đoạn văn bản ở đâu? Ở 400000, 600000 và 601000, phải không? Tôi có thể đọc một lời giải thích ở đâu? man pmapđã không giúp được gì.


phân đoạn văn bản thực sự chỉ được đọc, vì vậy nó ở mức 0000000000600000.
Danila Ladner

Cảm ơn! Không nên thực hiện phân đoạn văn bản?
Thorsten Staerk

1
Vâng, bạn đúng. r và rx. 0000000000400000 là tốt.
Danila Ladner 17/12/13

Câu trả lời:


14

Phân đoạn văn bản là ánh xạ ở 0x400000 - được đánh dấu 'rx' để có thể đọc và thực thi được. Ánh xạ ở 0x600000 là chỉ đọc, do đó gần như chắc chắn là phần ".rodata" của tệp thực thi. GCC đặt các chuỗi ký tự C vào một phần chỉ đọc. Ánh xạ ở 0x601000 là 'rw-', vì vậy đó có lẽ là đống nổi tiếng. Bạn có thể có malloc()1024 byte thực thi của mình và in ra địa chỉ để xem chắc chắn.

Bạn có thể có thêm một chút thông tin bằng cách tìm ra PID của quy trình của mình và thực hiện: cat /proc/$PID/maps- trên máy tính xách tay Arch của tôi, cung cấp thêm một số thông tin. Nó đang chạy kernel 3.12, do đó, nó cũng có /proc/$PID/numa_maps, và việc định vị cũng có thể cung cấp một cái nhìn sâu sắc nhỏ.

Những thứ khác để chạy trên tập tin thực thi: nmobjdump -x. Cái trước có thể cho bạn ý tưởng về những thứ khác nhau nằm trong bản đồ bộ nhớ, vì vậy bạn có thể thấy những gì trong phần 0x4000000 so với các phần khác. objdump -xhiển thị cho bạn các tiêu đề tệp ELF trong số rất nhiều thứ khác, vì vậy bạn có thể xem tất cả các phần, hoàn chỉnh với tên phần và liệu chúng có được ánh xạ trong thời gian chạy hay không.

Theo như tìm lời giải thích bằng văn bản về "cái gì ở đâu", bạn sẽ phải làm những việc như google cho "bố cục bộ nhớ ELF FILE". Xin lưu ý rằng định dạng tệp ELF có thể hỗ trợ bố trí bộ nhớ kỳ lạ hơn so với thông thường. GCC và Gnu ld và glibc đều đưa ra các giả định đơn giản hóa về cách một tệp thực thi được trình bày và sau đó ánh xạ vào bộ nhớ trong thời gian chạy. Có rất nhiều trang web tồn tại mục đích để ghi lại điều này, nhưng chỉ áp dụng cho các phiên bản Linux cũ hơn, các phiên bản cũ hơn của GCC hoặc glibc hoặc chỉ áp dụng cho các tệp thực thi x86. Nếu bạn không có nó, hãy nhận readelflệnh. Nếu bạn có thể viết chương trình C, hãy tạo phiên bản của riêng bạn objdump -xhoặc readelfđể làm quen với cách các tệp thực thi hoạt động và những gì trong đó.


2
Câu trả lời chính xác. Bây giờ, đống chương trình ở đâu? Và [anon] này có nghĩa là gì? Tôi phải làm gì để tìm hiểu điều này?
Thorsten Staerk 17/12/13

1
Bạn biết gì? Tôi đã sai về ánh xạ địa chỉ 0x601000 - có lẽ đó là đống. Bạn sẽ phải sử dụng readelfhoặc objdumptìm ra nó, và bất cứ điều gì bạn có thể thực hiện được. Hộp linux Arch của tôi sử dụng /usr/lib/libc-2.18.so, vì vậy nó khá khác so với hộp của bạn.
Bruce Ediger

2
0x601000là phân đoạn dữ liệu. Nó chứa .data, .bssvà có thể được mở rộng thông qua brk(). [anon]cho biết bộ nhớ không được hỗ trợ tập tin (được hỗ trợ bởi trao đổi), thu được thông qua mmap(). dlmalloc sử dụng brk()cho các phân bổ nhỏ hơn ~ 64Kb IIRC và mmap()cho các phân bổ lớn hơn. Heap là tất cả mọi thứ được phân bổ bởi malloc, cả phần mở rộng của phân đoạn dữ liệu và mmap()phân bổ dựa trên cơ sở.
ninjalj
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.