Trova quale istruzione di montaggio ha causato un errore di istruzione non valida senza debug

Question

Durante l'esecuzione di un programma che ho scritto in assembly, ottengo l'errore Illegal instruction. C'è un modo per sapere quale istruzione sta causando l'errore, senza eseguire il debug, perché la macchina su cui sto lavorando non ha un debugger o un sistema di sviluppo. In altre parole, compilo in una macchina e corro su un'altra. Non riesco a testare il mio programma sulla macchina che sto compilando perché non supportano SSE4.2. Il computer su cui sto eseguendo il programma supporta comunque le istruzioni SSE4.2.

Penso che forse perché ho bisogno di dire all'assemblatore (YASM) di riconoscere le istruzioni SSE4.2, proprio come facciamo con gcc passando il flag -msse4.2. O pensi che non sia la ragione? Qualche idea su come dire a YASM di riconoscere le istruzioni SSE4.2?

Forse dovrei intrappolare il segnale SIGILL e quindi decodificare SA_SIGINFO per vedere che tipo di operazione illegale fa il programma.

Answer 1

In realtà si verifica un errore di istruzione non valido perché il programma contiene un codice operativo non valido ma perché nel programma è presente un errore (ad esempio un buffer overflow) che fa saltare il programma in un indirizzo casuale con dati semplici o in codice ma non all'inizio dell'opcode.

Answer 2

Bene ... È ovviamente possibile inserire stampe di traccia, in modo da poter escludere rapidamente ampie aree del codice. Al termine, esegui per es.

$ objdump --disassemble my-crashing-program | less 

Quindi passare a es. la funzione che conosci causa l'errore e legge il codice, cercando qualcosa di strano.

Non sono completamente sicuro di come objdump visualizza istruzioni non valide, ma dovrebbero risaltare.

Answer 3

Per assemblaggi scritti a mano, sospetto un problema di gestione dello stack che si traduce in un ritorno al nulla. Scrivi una routine di debugging che salva ogni registro e inserisce una chiamata ad esso nella parte superiore di ogni funzione.

Poi si vedrà quanto lontano si ottiene ...

(a proposito, un buon editor e una buona conoscenza della sintassi della macro assemblatore sono bagnini durante la scrittura di codice macchina.)

Answer 4

Se è possibile abilitare core dump su quel sistema, basta eseguire il programma, lasciarlo andare in crash, quindi estrarre il core dump dalla macchina di destinazione sulla macchina di sviluppo e caricarlo in un GDB creato per eseguire il debug dell'architettura di destinazione, che dovrebbe indicare esattamente dove si è verificato l'arresto anomalo . Basta usare il comando core di GDB per caricare il file core nel debugger.

• Per abilitare i core dump sul bersaglio:

  ulimit -c unlimited 
  

• pseudo-file che controllano come il file core si chiamerà (cat questi per vedere la configurazione corrente, scrivere a loro per cambiare il configurazione):

  /proc/sys/kernel/core_pattern 
  /proc/sys/kernel/core_uses_pid 
  

Sul mio sistema, discariche una volta fondamentali sono abilitati, un programma di crash sarà scritto e un file semplicemente chiamato "core" nella directory di lavoro.Probabilmente è abbastanza buono per i tuoi scopi, ma cambiare il modo in cui il file di dump di base è denominato ti consente di conservare una cronologia dei dump di core, se necessario (forse per un problema più intermittente).

Answer 5

Recentemente si è verificato un arresto anomalo a causa di un codice di stato 132 di uscita (128 + 4: programma interrotto da un segnale + segnale di istruzione illegale). Ecco come ho capito quale istruzione stava causando l'incidente.

In primo luogo, ho attivato i core dump:

$ ulimit -c unlimited 

È interessante notare che la cartella da dove stavo correndo il binario conteneva una cartella denominata core. Ho dovuto dire Linux per aggiungere il PID per il core dump:

$ sudo sysctl -w kernel.core_uses_pid=1 

Poi ho eseguito il mio programma e ottenuto un nucleo di nome core.23650. Ho caricato il binario e il core con gdb.

$ gdb program core.23650 

Una volta che sono entrato in gdb, si presentò le seguenti informazioni:

Program terminated with signal SIGILL, Illegal instruction. 
#0 0x00007f58e9efd019 in ??() 

Ciò significa che il mio programma si è schiantato a causa di un'istruzione non valida in 0x00007f58e9efd019 memoria indirizzo. Poi sono passato a layout di asm per controllare l'ultima istruzione eseguita:

(gdb) layout asm 
>|0x7f58e9efd019 vpmaskmovd (%r8),%ymm15,%ymm0 
|0x7f58e9efd01e vpmaskmovd %ymm0,%ymm15,(%rdi) 
|0x7f58e9efd023 add $0x4,%rdi 
|0x7f58e9efd027 add $0x0,%rdi 

Era istruzioni vpmaskmovd che ha causato l'errore. Apparentemente, stavo cercando di eseguire un programma per l'architettura AVX2 su un sistema che non supporta il set di istruzioni AVX2.

$ cat /proc/cpuinfo | grep avx2 

Infine, ho confermato vpmaskmovd is an AVX2 only instruction.