Le Fri, 15 Feb 2008 14:35:36 +0800, "Peter Teoh" <htmldeveloper@xxxxxxxxx> a écrit : > I go to /proc and "cat 4073/maps" (4073 is pid of one the userspace > process - "sleep 1000 &" for example): > > 004ee000-00509000 r-xp 00000000 03:02 4417239 /lib/ld-2.6.so > 00509000-0050a000 r--p 0001a000 03:02 4417239 /lib/ld-2.6.so > 0050a000-0050b000 rw-p 0001b000 03:02 4417239 /lib/ld-2.6.so > > Notice that the loader (ld.so) above is loaded THREE times into the > different range of virtual mem - with different read/write/exe > attributes assigned to it. But the size is the same. Why such > inefficiency? The process map for windows don't have such features. > And same below as well? (if the space an be freed up, saving of > memory is considerable) It is not loaded three times. The first region is the code segment (readable, executable), which starts at offset 0 in the /lib/ld-2.6.so file. The second region is the read-only data segment (readable), which starts at offset 0x1a000 is the /lib/ld-2.6.so file. The third region is the writable data segment (readable, writable), which starts at offset 0x1b000 is the /lib/ld-2.6.so. So, various parts of the same file (/lib/ld-2.6.so) are mapped in different virtual regions, depending on the access rights we want to give to these regions. The size is not the same: the number 4417239 is the inode number of the /lib/ld-2.6.so file. On my system: b7f58000-b7f74000 r-xp 00000000 03:02 26216 /lib/ld-2.7.so b7f74000-b7f76000 rw-p 0001b000 03:02 26216 /lib/ld-2.7.so $ ls -i /lib/ld-2.7.so 26216 /lib/ld-2.7.so See the 26216 is the inode number of the file. 03:02 is the major/minor of the block device storing the file. On my system: $ mount /dev/hda2 on / type ext3 (rw,errors=remount-ro) $ ls -l /dev/hda2 brw-rw---- 1 root disk 3, 2 2008-02-14 16:00 /dev/hda2 You find here again the major 3 and minor 2. Then, looking inside the /lib/ld-2.7.so file, using "readelf -l" to see the program headers: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x00000000 0x00000000 0x1b9b4 0x1b9b4 R E 0x1000 LOAD 0x01bcc0 0x0001ccc0 0x0001ccc0 0x008f4 0x009a8 RW 0x1000 DYNAMIC 0x01bf28 0x0001cf28 0x0001cf28 0x000b8 0x000b8 RW 0x4 GNU_EH_FRAME 0x01b520 0x0001b520 0x0001b520 0x000f4 0x000f4 R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4 GNU_RELRO 0x01bcc0 0x0001ccc0 0x0001ccc0 0x00328 0x00328 R 0x1 You see two sections with the LOAD type. This type indicates that these sections have to be mapped through virtual regions. And you find again the section readable/executable at offset 0x0, and the readable/writable section at offset 0x01bcc0. > 08048000-0804c000 r-xp 00000000 03:02 2910727 /bin/sleep > 0804c000-0804e000 rw-p 00003000 03:02 2910727 /bin/sleep Code and data of the /bin/sleep binary. See "readelf -l /bin/sleep". > 0804e000-0806f000 rw-p 0804e000 00:00 0 [heap] The heap is an area that can be extended/reduced using the brk() system call. It is used by the userspace memory allocator malloc() to get some memory from the kernel. > 4881d000-4896b000 r-xp 00000000 03:02 7040012 /lib/libc-2.6.so > 4896b000-4896d000 r--p 0014e000 03:02 7040012 /lib/libc-2.6.so > 4896d000-4896e000 rw-p 00150000 03:02 7040012 /lib/libc-2.6.so Code region, read-only data region, writable data region. Again, see "readelf -l /lib/libc-2.6.so". Sincerly, Thomas -- Thomas Petazzoni, Free Electrons Free Embedded Linux Training Materials on http://free-electrons.com/training (More than 1500 pages!)
Attachment:
signature.asc
Description: PGP signature
