My general debugging process is to dump a listing of the file then walk through it to make sure what I'm wanting to generate is being generated, then I use strace to make sure system call arguments and return values are correct, finally I throw the code in GDB and step to various INT 3 breakpoints I've put in the code and monitor the registry. I almost never worry about the disassembler unless I'm getting a seg-fault, in which case I disassemble to see what instruction it's happening on.
On windows it's a bit of a different story, I like developing in the command line and I don't have GDB on that box. So I do actually use the "mental execution" process that Keith mentioned. That works until something really obscure happens and it forces me to step out of the command prompt and load up OllyDBG. Even with "mental execution" I still prefer to go by listing files than disassembler dumps because they give a much clearer output to read.
As far as the correctness of his sentence... I would have probably used the term "source profiling" instead, but I'm not one to argue semantics like that. As far as it being an integral part of the debugging process, I put it on the level of DBGPRINT macros like:
%macro STRING 2
[SECTION .data]
str %+ %1 DB %2
str %+ %1 %+ .Size EQU ($-str %+ %1)
__SECT__
%endm
%macro DBGPRINT 1-*
%ifdef __DEBUG__
%push _DBGPRINT_
Push Edx
Push Ecx
Push Ebx
Push Eax
%ifstr %1
STRING %%tmp, %1
Mov Edx, str %+ %%tmp %+ .Size
Mov Ecx, str %+ %%tmp
Mov Ebx, STDOUT_FILENO
Mov Eax, SYS_WRITE
Int 80h
%elifnum %1
STRING %%tmp, %1
Mov Edx, str %+ %%tmp %+ .Size
Mov Ecx, str %+ %%tmp
Mov Ebx, STDOUT_FILENO
Mov Eax, SYS_WRITE
Int 80h
%endif
Pop Eax
Pop Ebx
Pop Ecx
Pop Edx
%pop
%endif
%endm
Where you throw in comments to be displayed during runtime to track down where an application is having problems. Yea, it's useful but it's still better just to throw an INT3 in there and run it through a debugger. Same goes for "mental execution", it's good for tracking down program flow errors, but most decent debuggers can help you far better by simply stepping through the program's execution.
