It is always showed when debugging in the right pane. Just place breakpoint and run the app.
BTW, there is a problem with viewing release code assembly (useful when doing optimizations). I tend to solve this by placeing __BREAK__, which is essentially *(int *)0 = 0; to crash the code at the right place and invoke debugger
mr_ped Messages: 825 Registered: November 2005 Location: Czech Republic - Praha
Experienced Contributor
hm... calling breakpoint interrupt and rewriting memory at address 0 with 0 is really not the equivalent. INT 3 summons breakpoint interrupt in DOS (Win16/32), and after resume the thread will continue, while "*(int *)0 = 0;" does rewrite protected memory, so the thread will crash. Maybe minor difference when you want to check the code, but can be helpfull when you are just steping trough some code.
I wonder why linux does not implement (or does it?) "INT 3" as breakpoint, because AFAIK (at least in the age of 286/386/486 CPUs) int 3 is the only 1B long interrupt instruction, and the main purpose for this instruction was exactly ability to use breakpoints easily in debuggers. (at least the code should *not* crash at linux, as the INT 3 should be simple RET interrupt when no debugger is running)
Well, actually I think Linux uses int 3 as well, I was rather referring to syntax (it would need #ifdef because of assembly).
Anyway, I do not thing this is the most importatnt thing in the world. Thankfuly, all systems are able to deal with NULL assignemnt well a this is just a tool for experimenting with the code, nothing that should be left in producuction app...