La sintassi di nasm e' simile a quella di TASM ma ci sono alcuni dettagli per cui non e' sempre possibile compilare codice vecchio senza modifiche
Prima di tutto GEdit non ha preimpostata la colorazione della sintassi dei file .asm ma si puo' rimediare con i comandi
wget http://www.carminebenedetto.net/_downloads/asm-intel.lang
sudo cp asm-intel.lang /usr/share/gtksourceview-3.0/language-specs/
per compilare il codice (compreso della tabella dei simboli per il debug)
nasm -f elf -F dwarf mand_linux.asm
ld mand_linux.o -o mand_linux
per rimuovere i codici di debug (ed ottenere un eseguibile nettamente piu' snello) si puo' aggiungere in fase di link lo switch --strip-all come segue
ld mand_linux.o -o mand_linux --strip-all
per compilare codice a 32 bit su un sistema operativo a 64 bit
nasm -f elf -F dwarf mand_linux.asm
ld -m elf_i386 mand_linux.o -o mand_linux
con nasm si possono compilare anche eseguibili DOS (i vecchi file .COM)
nasm -f bin -o mand_dos.com mand_dos.asm
dosbox mand_dos.com -exit
per compilare codice DOS in formato COM si deve aggiungere in testa al codice la linea
org 100h
il programma DOS puo' essere verificato con DOSBOX
dosbox programma.com -exit
Per decompilare o fare debugging, al posto del complicato gdb, puo' essere molto comodo usare ddd, una IDE di gdb in cui si puo' fare debug step-by-step con breakpoint (tasto destro sulla riga di codice), watch delle variabili e dei valori dei registri del processore
E' anche possibile editare direttamente il codice e ricompilare senza uscire da ddd (questa funzione mi ha creato qualche problema a dire il vero perche' la finestra di debug non sempre e' aggiornata con gli aggiornamenti del codice)
Nel caso di core dump del codice si puo' eseguire
gdb file_eseguibile file_core
seguito dal comando backtrace per capire dove si e' generato il segmentation fault. All'interno di ddd si puo' lanciare l'esecuzione (senza breakpoint), attendere il core dump e poi fare il backtrace direttamente dalla IDE
