При запуске программы, написанной на сборке, я получаю ошибку Illegal instruction. Есть ли способ узнать, какая команда вызывает ошибку, без отладки, потому что машина, на которой я запущена, не имеет отладчика или какой-либо системы разработки. Другими словами, я скомпилируюсь на одной машине и запускаю другую. Я не могу проверить свою программу на машине, которую я компилирую, потому что они не поддерживают SSE4.2. Машина, на которой я запускаю программу, все равно поддерживает инструкции SSE4.2.
Я думаю, это может быть потому, что я должен сказать ассемблеру (YASM), чтобы узнать инструкции SSE4.2, так же, как мы делаем с gcc, передав ему флаг -msse4.2. Или вы считаете, что это не причина? Любая идея, как сказать YASM распознать инструкции SSE4.2?
Может быть, я должен захватить сигнал SIGILL, а затем декодировать SA_SIGINFO, чтобы узнать, какую незаконную операцию выполняет программа.
На самом деле часто вы получаете ошибку незаконной инструкции не потому, что ваша программа содержит недопустимый код операции, а потому, что в вашей программе есть ошибка (например, переполнение буфера), которая заставляет вашу программу переходить в случайный адрес с простыми данными или кодом но не в начале кода операции.
Недавно я испытал сбой из-за кода статуса выхода 132 (128 + 4: программа, прерванная сигналом + незаконным сигналом команды). Здесь, как я выяснил, какая инструкция вызвала сбой.
Сначала я включил основные дампы:
$ ulimit -c unlimited
Интересно, что папка, откуда я запускала двоичный файл, содержала папку с именем core. Я должен был сказать Linux, чтобы добавить PID к дампу ядра:
$ sudo sysctl -w kernel.core_uses_pid=1
Затем я запустил свою программу и получил ядро с именем core.23650. Я загрузил двоичный код и ядро с помощью gdb.
$ gdb program core.23650
Как только я попал в gdb, он обнаружил следующую информацию:
Program terminated with signal SIGILL, Illegal instruction.
#0 0x00007f58e9efd019 in ?? ()
Это означает, что моя программа потерпела крах из-за незаконной инструкции в адресной памяти 0x00007f58e9efd019. Затем я переключился на макет asm, чтобы проверить выполненную последнюю команду:
(gdb) layout asm
>|0x7f58e9efd019 vpmaskmovd (%r8),%ymm15,%ymm0
|0x7f58e9efd01e vpmaskmovd %ymm0,%ymm15,(%rdi)
|0x7f58e9efd023 add $0x4,%rdi
|0x7f58e9efd027 add $0x0,%rdi
Это была инструкция vpmaskmovd, которая вызвала ошибку. По-видимому, я пытался запустить программу, предназначенную для архитектуры AVX2, в системе, в которой отсутствует поддержка набора инструкций AVX2.
$ cat /proc/cpuinfo | grep avx2
Наконец, я подтвердил vpmaskmovd - это только инструкция AVX2.
Если вы можете включить дампы ядра в этой системе, просто запустите программу, дайте ей сбой, затем вытащите основной дамп с целевой машины на вашу машину разработки и загрузите ее в GDB, созданный для отладки целевой архитектуры, - которая должна скажите, где именно произошел сбой. Просто используйте команду GDB core для загрузки основного файла в отладчик.
Чтобы включить дампы ядра для цели:
ulimit -c unlimited
псевдофайлы, которые управляют тем, как будет называться основной файл (cat, чтобы увидеть текущую конфигурацию, написать им, чтобы изменить конфигурацию):
/proc/sys/kernel/core_pattern
/proc/sys/kernel/core_uses_pid
В моей системе, как только основные дампы будут включены, программа сбоев напишет файл, просто названный "ядром" в рабочем каталоге. Это, вероятно, достаточно хорошо для ваших целей, но изменение имени имени ядра дампа позволяет вам сохранить историю дампов ядра, если это необходимо (возможно, для более прерывистой проблемы).
Для рукописной сборки я подозреваю, что проблема управления стеком приводит к возврату в никуда. Напишите процедуру отладки распечатки, которая сохраняет каждый регистр и вставляет вызов к ней в верхней части каждой функции.
Затем вы увидите, как далеко вы достигнете...
(BTW, хороший редактор и хорошее понимание синтаксиса макросов ассемблера являются lifesavers при написании машинного кода.)
Ну... Конечно, вы можете вставить трассировочные отпечатки, чтобы вы могли быстро исключить большие области кода. Когда вы это сделаете, запустите, например,
$ objdump --disassemble my-crashing-program | less
Затем перейдите к, например, функция, которую вы знаете, вызывает ошибку, и читайте код, ища все, что выглядит странно.
Я не совсем уверен, как objdump отображает незаконные инструкции, но они должны выделяться.