Submitted by In this article we’ll walk through an example of how to interpret a closed source program, how to analyze its behavior, and how to ultimately alter that behavior to do what we want. These techniques are well known within many circles, but few tutorials exist to help people get started. The context for this example investigation is the linker’s subsystem field generation, but the techniques can be applied to other problems that seem interesting.
All my favorite debuggers are on windows. There’s IDA Pro, SoftIce, etc.
I haven’t found anything production quality that I really like on linux though. While GDB is a comprehensive cross platform debugger, I really don’t like it very much and most linux debugging tools (like DDD) are just a thin front end for GDB.
What I’d really like is a good alternative console debugger? Something like good old turbo debugger for dos would be perfect.
That is an aspect of development on Linux that has been of much interest to me (turbo debugger was fantastic at its time).
Right now I use a mix of lldb and gdb and experiment with many front ends. When developing with Qt I use the Qt Creator embedded front end (it is quite good). When doing stuff on terminal I use cgdb, Emacs (you read it right!) dbgr or vim vebugger. For GUI there are also Nemiver (GNOME) and kdbg (KDE), both are way better than DDD. And never ever forget about the good bashdb for your shell scripts!
As you know, modern debuggers are really complex these days and it is not easy to create a simple one as can be kind of proved by lack of multiple alternatives, like what you see with other tools on more mundane tasks. It is the same pattern we see with compilers and build systems, probably because our environments got really complex with threads, IPC, new processor instructions, GPU and all these new stuffs we must deal with.
My experience with lldb has not been very good at all. Almost every command is more typing than in gdb (but still cryptic enough that I can’t simply guess things I don’t know the name of), and a few commands simply have no equivalent in gdb.
That said, I really prefer gdb or even lldb over the MSVC debugger. I should also explain that I began C++ development with MSVC, and later learned how to use gdb for debugging, so I’ve really lived in both worlds. The visualizers in Visual Studio for any non-trivial type are really annoying to actually traverse (much more so than the print statements in gdb), and while it’s nice to be able to click the line I want a breakpoint on, more often I actually just want to set by function name, which is not very difficult in gdb.
Did you look at the article? It sounds like WinDbg is what you’re looking for. Here I wasn’t trying to use real symbols that would exist from code whose source is available, but when those symbols exist, doing what you describe is what it does well.
It also sounds like I should write something up about writing debugger extensions, which are useful when you want to automatically traverse some reasonably sophisticated data structure (list, tree, hash table etc), where expanding each pointer manually would be inefficient. The command line nature of WinDbg et al make it very straightforward to dump out lots of information about the state of your program in a format that is meaningful to you; MSVC just lacks a lot of context about the structures you’re building and how to display them intelligently.
I did read the article, and I have used WinDbg, and I do not find it particularly better than gdb.
I forgot to add one more debugger I have played with that showed promise: voltron (get it on github).
Happy debugging !
I never really used Turbo Debugger, but the WinDbg package includes cdb/ntsd/kd which are designed for command line use. Until recently I used these in preference to WinDbg; they have the same engine and are quite interchangeable. As you saw in the article, often what I do doesn’t benefit in any way from the GUI.
A new GDB frontend was just announced in Reddit’s /r/rust/, in case anyone wants to take a look at it.
https://github.com/cs01/gdbgui/
Caveat: These are still listed as TODOs:
* Hover over a variable in source code to see its value
* Embed plotting tools to plot a variable’s value over time
* Assign values to variables / memory addresses
* Embed a binary/decimal/hex calculator
Edited 2017-03-01 19:45 UTC