2

Я понимаю, что команда strace использует ptrace(PTRACE_PEEKUSER, child, __builtin_offsetof(struct user, regs.orig_eax)) чтобы найти индекс системного вызова, в который попадает дочерний объект трассировки. Затем, чтобы перевести индекс в имя функции syscall, он построил таблицы, сделанные на основе поиска заголовков исходного кода linux, присутствующих в установке.

Этот метод должен быть недокументированным и склонным к сбою, поскольку расположение и синтаксис объявлений исходного кода не документированы, должны быть найдены с помощью grepping и могут изменяться неизвестными способами. Я правильно сказал это?

Если это так, то почему бы strace не использовать следующий метод, с как мне кажется, проще, опирается только на документацию и, таким образом , надежно.

В начале первого запуска после перезагрузки strace отправляет тестовый системный вызов, по одному для каждой функции системного вызова, перехватывает его и наблюдает, какой индекс системного вызова использует этот дочерний элемент. Это дает полную и правильную пользовательскую таблицу, которая может быть сохранена в файле, известном для дальнейших вызовов strace .

Я уверен, что этот метод должен быть рассмотрен, так как он не является чем-то особенно гениальным. Так что должно быть что-то не так с этим. Что случилось??

1 ответ1

1

Потому что не существует понятия имени системного вызова на том низком уровне. strace никак не может сказать: «Эй, давайте сделаем вызов fcntl() и посмотрим, что это за число!». Он может совершать звонки только на основе номеров системных вызовов. Это связано с тем, что системный вызов выполняется, когда номер системного вызова сохраняется в регистре eax или rax , а процесс вызывает int 0x80 или syscall .

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .