почему proc/ID/maps имеет несколько записей для разделяемых библиотек

Я смотрю proc/ID/maps под встроенным Linux, и я заметил, что некоторые общие библиотеки появляются несколько раз на карте памяти процесса, почему это так?

40094000-400d9000 r-xp 00000000 b3:09 723        /system/lib/libc.so
400d9000-400da000 ---p 00000000 00:00 0 
400da000-400dc000 r-xp 00045000 b3:09 723        /system/lib/libc.so
400dc000-400de000 rwxp 00047000 b3:09 723        /system/lib/libc.so
400de000-400e9000 rwxp 00000000 00:00 0 
400e9000-400ed000 r-xp 00000000 b3:09 770        /system/lib/libgccdemangle.so
400ed000-400ee000 ---p 00000000 00:00 0 
400ee000-400ef000 r-xp 00004000 b3:09 770        /system/lib/libgccdemangle.so
400ef000-400f0000 rwxp 00005000 b3:09 770        /system/lib/libgccdemangle.so
40102000-40103000 r-xp 00000000 b3:09 869        /system/lib/libstdc++.so
40103000-40104000 r-xp 00000000 b3:09 869        /system/lib/libstdc++.so
40104000-40105000 rwxp 00001000 b3:09 869        /system/lib/libstdc++.so
40105000-40112000 r-xp 00000000 b3:09 738        /system/lib/libcutils.so
40112000-40113000 r-xp 0000c000 b3:09 738        /system/lib/libcutils.so
40113000-40114000 rwxp 0000d000 b3:09 738        /system/lib/libcutils.so

person stdcall    schedule 07.01.2014    source источник
comment
его ссылка может вам помочь: stackoverflow.com/questions/20726346/   -  person Phorus    schedule 11.04.2016


Ответы (1)


Поскольку общая библиотека ELF имеет, как и исполняемый файл, несколько сегментов: часто это "текст" только для чтения (который mmap является общим, поэтому все процессы, использующие этот сегмент, совместно используют часть физической памяти), и "данные" сегмент для чтения и записи (для статических или "глобальных" переменные и, возможно, также PLT...), частные для каждого процесса.

Это очень подробно объясняется в статье Дреппера: Как написать общую библиотеку.

person Basile Starynkevitch    schedule 17.07.2014