У меня нет целевого исполняемого файла gdb, и у меня даже нет стека, соответствующего этой цели. В любом случае я хочу пошагово, чтобы я мог проверить, что происходит в моем коде сборки, потому что я не эксперт в сборке x86. К сожалению, GDB отказывается выполнять эту простую отладку на уровне сборки. Это позволяет мне устанавливать и останавливаться на соответствующей точке останова, но как только я пытаюсь перейти на один шаг вперед, gdb сообщает об ошибке «Не удается найти границы текущей функции», и EIP не изменяется.
Дополнительные детали:
Машинный код был сгенерирован операторами gcc asm, и я скопировал его в то место памяти ядра, где он выполняется, из вывода objdump -d. Я бы не возражал против простого способа использовать загрузчик для загрузки моего объектного кода на перемещенный адрес, но имейте в виду, что загрузка должна выполняться в модуле ядра.
Я полагаю, другой альтернативой было бы создание поддельного модуля ядра или файла отладочной информации для передачи gdb, чтобы заставить его поверить, что эта область находится в программном коде. gdb отлично работает с самим исполняемым файлом ядра.
(Для тех, кто действительно хочет знать, я вставляю код во время выполнения в пространство данных ядра Linux внутри виртуальной машины VMware и отлаживаю его из gdb удаленно отлаживая ядро через встроенную заглушку gdb VMware Workstation. Обратите внимание, что я не пишу ядро эксплойтов; я аспирант по безопасности, пишу прототип.)
(Я могу установить точку останова для каждой инструкции внутри моей сборки. Это работает, но через некоторое время станет довольно трудоемким, поскольку размер сборочных инструкций x86 меняется, а расположение сборки будет меняться каждый раз при перезагрузке.)