On Wed, Sep 24, 2014 at 10:30:49PM -0700, Walter Bright via Digitalmars-d wrote: > On 9/24/2014 9:43 PM, H. S. Teoh via Digitalmars-d wrote: > >printf debugging FTW! :-P > > There's more than that, but yeah. Most of my types I'll write a > "pretty printer" for, and use that. No conceivable debugger can guess > how I want to view my data. > > For example, I can pretty-print an Expression as either a tree or in > infix notation.
gdb does allow calling your program's functions out-of-band in 'print'. I've used that before when debugging C++, which is a pain when lots of templates are involved (almost every source line is demangled into an unreadable glob of <> gibberish 15 lines long). Wrote a pretty-printing free function in my program, and used `print pretty_print(my_obj)` from gdb. Worked wonders! Having said that, though, I'm still very much a printf/writeln-debugging person. It also has the benefit of working in adverse environments like embedded devices where the runtime environment doesn't let you run gdb. > >I don't agree with that. I think symbolic debuggers should be > >improved so that they *can* become useful with high level > >abstractions. For example, if debuggers could be made to understand > >templates and compile-time constants, they could become much more > >useful than they are today in debugging high-level code. > > The fact that they aren't should be telling. Like maybe it's an > intractable problem :-) sort of like debugging optimized code. When all else fails, I just disassemble the code and trace it along side-by-side with the source code. Not only it's a good exercise in keeping my assembly skills sharp, you also get to see all kinds of tricks that optimizers nowadays can do in action. Code hoisting, rearranging, register assignments to eliminate subsequent loads, vectorizing, etc.. Fun stuff. Not to mention the thrill when you finally identify the cause of the segfault by successfully mapping that specific instruction to a specific construct in the source code -- not a small achievement in this day and age of optimizing compilers and pipelining, microcode CPUs! Nevertheless, I think there is still room for debuggers to improve. Recently, for example, I learned that gdb has acquired the ability to step through a program backwards. Just missed the point in your program where the problem first happened? No problem, just step backwards until you get back to that point! Neat stuff. (How this is implemented is left as an exercise for the reader. :-P) T -- Stop staring at me like that! It's offens... no, you'll hurt your eyes!
