вопрос вывода strace

Я запускаю программу как на CentOS, так и на Debian. Результат точно такой же, но в Centos я выделяю 3 строки жирным шрифтом, а в Debian - нет. О чем эти 3 строчки и как я могу получить их в Debian?

execve("./z1", ["./z1"], [/* 31 vars */]) = 0
brk(0)                                  = 0x8458000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f41000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/home/myuser/public_html/libs/libmudflap.so.0", 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\0PJ\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=105432, ...}) = 0
mmap2(NULL, 943136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xd89000
mmap2(0xda2000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19) = 0xda2000
mmap2(0xda3000, 836640, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xda3000
close(3)                                = 0
open("/home/myuser/public_html/libs/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\320m\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1327556, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f40000
mmap2(NULL, 1337704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x891000
mprotect(0x9d1000, 4096, PROT_NONE)     = 0
mmap2(0x9d2000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x140) = 0x9d2000
mmap2(0x9d5000, 10600, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x9d5000
close(3)                                = 0
open("/home/myuser/public_html/libs/libdl.so.2", 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@\n\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=9736, ...}) = 0
mmap2(NULL, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x74e000
mmap2(0x750000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x750000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f3f000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f3f6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
open("/dev/urandom", O_RDONLY)          = 3
read(3, "\f\233\37", 3)                 = 3
close(3)                                = 0
mprotect(0x750000, 4096, PROT_READ)     = 0

c linux binary centos strace
person Jason Pilo    schedule 30.04.2011    source источник
comment
Почему вы хотите использовать их в Debian, если не знаете, что они делают? Какую проблему вы пытаетесь решить?   -  person viraptor    schedule 01.05.2011
comment
Вы всегда можете подключить gdb, установить точку останова на open, добавить условие для filenam /dev/urandom и запустить ... Вы точно увидите, что это вызывает   -  person sehe    schedule 01.05.2011

Ответы (1)


arrow_upward
4
arrow_downward

Я не думаю, что это имеет какое-то отношение к strace. Я не уверен, но, вероятно, это как-то связано с тем, как вещи расположены в памяти. Я знаю, что некоторые системы помещают части двоичного файла в случайные места в памяти для защиты от злонамеренных действий. Это называется рандомизацией макета адресного пространства (ASLR). Я предполагаю, что CentOS использует это, а Debian - нет. См. этот пост об отключении ASLR в CentOS. Попробуйте это и посмотрите, показывает ли strace по-прежнему открытие / dev / urandom.

Дело в том, что причиной несоответствия может быть ваша система, а не strace или программа.

-- Редактировать --

Так что я могу ошибаться выше. Я провел массу исследований по этому вопросу и сумел сузить круг вопросов. Я обнаружил, что, скорее всего, эти вызовы выполняет библиотека. Метод, который я использовал, был немного сложным, но выполнимым. Если вам все еще интересно, как это делается, см. этот пост.

Я выполнил эту отладку с помощью eye of gnome (eog), потому что написанная мною простая тестовая программа не запускала чтение urandom. Оказывается, в моем случае виноват Gkt +, он использует случайные числа для создания уникальных идентификаторов для некоторых объектов. Мне любопытно узнать, что вы используете в программе, которая выполняет эти вызовы. На данный момент я сомневаюсь, что это ASLR.

person zdav    schedule 30.04.2011