Using GDB to debug Asm is... certainly a choice.
We had better tools 30 years ago when pure assembly work was more common. You'd often run in the debugger by default.
Yet GDB lives on
Why? Back in the day, after the pain of debugging on Timex, and MS-DOS debug, the confort of Turbo Assembler debugger felt really nice.
Gdb is an excellent debugger for assembly, even when the original code was written in C
I would automatically type
(gdb) x/4i $pc
when opening a coredump out of habit.
But using nasm, then looking as gas style assembly in the debugger might be a bit more jarring.
What's the better choice?
Setting a breakpoint in the debug registers DB0 through DB7 and dumping registers and memory in your own debug exception handler.
We had better tools 30 years ago when pure assembly work was more common. You'd often run in the debugger by default.
Yet GDB lives on
Why? Back in the day, after the pain of debugging on Timex, and MS-DOS debug, the confort of Turbo Assembler debugger felt really nice.
Gdb is an excellent debugger for assembly, even when the original code was written in C
I would automatically type
(gdb) x/4i $pc
when opening a coredump out of habit.
But using nasm, then looking as gas style assembly in the debugger might be a bit more jarring.
What's the better choice?
Setting a breakpoint in the debug registers DB0 through DB7 and dumping registers and memory in your own debug exception handler.