Hello folks! I am not sure if this is the right place to do this thing but here it goes.
Some time ago my debugger was here on the project list, but unfortunately I had to focus on other
things and project went under the water. Last October I finally got a chance to revive it and since
then I have managed to get debugger into a good shape. A lot of time was spent on making sure that current
set of features worked with all of the edge cases, like stepping though the exceptions, making sure that PDB parser
is compatible with recent versions of the MSVC C/C++ compilers, and so on. Also I have manged to
replace the DIA(Debug Interface Access) SDK that was used to read PDB files.
I knew from the start of the project that eventually I will have to replace that SDK, because
that is a huge black-box that was dragging the project down. I kid you not, but it took me same
amount of time to write my own parser as it took me to integrate that SDK. Microsoft never stops
to amaze! Next on the list was to replace the StackWalk64 from the dbghelp.dll which is 1mb in size,
and that is a lot code to keep around just for one call. To my surprise it is very easy to write a stack
unwinder for win64.
Last couple days I have spent on making sure that debugger works not only on my machine.
I have tested on three different setups and couple virtual boxes and it worked fine.
This means that any obvious mistakes were eliminated and it can be shared with others.
You can leave your feedback here in comments or just email me [email protected].
You can find a little demo that I have put together here on yotuube,
and link to download the standalone executable. Thank you.
Some time ago my debugger was here on the project list, but unfortunately I had to focus on other
things and project went under the water. Last October I finally got a chance to revive it and since
then I have managed to get debugger into a good shape. A lot of time was spent on making sure that current
set of features worked with all of the edge cases, like stepping though the exceptions, making sure that PDB parser
is compatible with recent versions of the MSVC C/C++ compilers, and so on. Also I have manged to
replace the DIA(Debug Interface Access) SDK that was used to read PDB files.
I knew from the start of the project that eventually I will have to replace that SDK, because
that is a huge black-box that was dragging the project down. I kid you not, but it took me same
amount of time to write my own parser as it took me to integrate that SDK. Microsoft never stops
to amaze! Next on the list was to replace the StackWalk64 from the dbghelp.dll which is 1mb in size,
and that is a lot code to keep around just for one call. To my surprise it is very easy to write a stack
unwinder for win64.
Last couple days I have spent on making sure that debugger works not only on my machine.
I have tested on three different setups and couple virtual boxes and it worked fine.
This means that any obvious mistakes were eliminated and it can be shared with others.
You can leave your feedback here in comments or just email me [email protected].
You can find a little demo that I have put together here on yotuube,
and link to download the standalone executable. Thank you.
Edited by Nikita Smith
on
Reason: fixed download link
Great demo!
What's on the list to do before this thing is shippable?
What's on the list to do before this thing is shippable?
Thanks! Right now at the top of the list there are several things: data breakpoints, value editor for the inspector, and disassembler(right now it just dumps instructions).
Wow, this is really nice...
I haven't spent much time with the debugger yet, but I already have a few minor suggestions.
1. CDBG sounds a lot like CGDB, which is a very popular debugger for linux (a curses front-end to GDB). I would recommend picking a new name, lest people confuse the two.
2. It's probably worth putting in the README that <backtick> opens the console, and <escape> returns to the debugger.
3. Just caught a typo. [wdir] returns "Wroking directory: ...", where it should say "Working directory: ..."
4. I cannot step into any functions.
5. The active line is usually about 4-steps behind where the program is actually executing...
For example:
I'm really looking forward to playing with this more, thanks a lot!
I haven't spent much time with the debugger yet, but I already have a few minor suggestions.
1. CDBG sounds a lot like CGDB, which is a very popular debugger for linux (a curses front-end to GDB). I would recommend picking a new name, lest people confuse the two.
2. It's probably worth putting in the README that <backtick> opens the console, and <escape> returns to the debugger.
3. Just caught a typo. [wdir] returns "Wroking directory: ...", where it should say "Working directory: ..."
4. I cannot step into any functions.
5. The active line is usually about 4-steps behind where the program is actually executing...
For example:
1 2 3 4 | > 121 swapbuffers(dc); // nothing happens 122 blahblah(); 123 blah++; > 124 } // buffer is actually swapped (or whatever else I did 4 lines ago) |
I'm really looking forward to playing with this more, thanks a lot!
Edited by mapper
on
mapper
4. I cannot step into any functions.
It happens when you build with incremental mode.
"/link -incremental:no" to disable it.
I've reported this bug a while ago.
Edited by hollowshrine
on