| |||||||||||||
an intermediate examplean intermediate examplePosted May 3, 2007 4:05 UTC (Thu) by roelofs (guest, #2599)Parent article: A tale of two release cycles gdb would seem to represent an intermediate stage: moderately regular releases, but with (some) bugs that never seem to get fixed. :-/ In particular, those of us writing C++ code have been bitten time and again by the inability to set constructor breakpoints based on source-code line numbers (and perhaps in other circumstances). This apparently broke with the release of GCC 3.0 and was first reported more than four years ago (against gdb 5.3 and g++ 3.2.1, if not earlier); we're now up to gdb 6.6, and we merely have "some hopes" that it will be fixed in the next release. Granted, it's a difficult problem, but...other hard problems have been solved in, say, a mere two or three years. :-) Of course, it doesn't help that most of us (including myself) don't have the expertise to help out, nor that it's an FSF project and therefore has the (small) additional hurdle of requiring copyright assignments from potential contributors. So I really can't complain too much ("...but sometimes I still do"). Greg
(Log in to post comments)
an intermediate example Posted May 3, 2007 7:16 UTC (Thu) by bkoz (guest, #4027) [Link]
...the continuing saga of gdb vs. C++ means that elaborate logging structures have been built to debug basic constructs. I consider this a reversion to printf.
I don't think this sad state of affairs has anything to do with the gdb release strategy, but instead is more about gdb vs. g++ when dealing with debug info generation, the difficulty of representing and correctly displaying the full complexity of C++ types with scope info, lack of interest or skill in the gdb community, and the constraints of having to support a wide variety of devices in gdb, many of them obscure, with severe technical limitations, and often poorly documented.
GDB Alternatives Posted May 3, 2007 8:42 UTC (Thu) by alex (subscriber, #1355) [Link] Much as I love my GDB command line I can't help but think it's one of those core apps that could do with a step back and re-write. I've looked at the code a few times and it's not pretty which I think makes it a huge learning curve for any wanabe hacker.
Of course it would require some people to actually start that effort. Have you seen any alternatives to GDB? Could this be an area where the monoculture stiffles true innovation in development?
GDB Alternatives Posted May 3, 2007 9:19 UTC (Thu) by scottt (subscriber, #5028) [Link] There is frysk: http://sourceware.org/frysk/If don't mind debugging your C++ program with a debugger written in Java.
GDB Alternatives Posted May 3, 2007 11:08 UTC (Thu) by mtk77 (guest, #6040) [Link] I am worried about frysk. It seems that the answer to all problems with gdb is "frysk will make gdb obsolete" but the look like they solve completely different problems.
I'm sure it's not deliberate, but it seems that the almost Microsoft-esque tactic of preannouncing something has the same effect - of putting off potential competitors.
There is no good reason that free software cannot produce something of the quality of the wonderful proprietary debugger TotalView but no work is being done in that direction.
GDB Alternatives Posted May 4, 2007 4:27 UTC (Fri) by mitchskin (subscriber, #32405) [Link] Robert O'Callahan (of Mozilla) isn't rewriting gdb, but he's working on an execution recorder that provides enough data for a debugger to reconstruct an entire program execution run down to the instruction level.
gdb's fundamental problem Posted May 3, 2007 17:40 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] gdb is architected to assume that there is a one-to-one correspondence between source code lines and object code positions. This obviously breaks with templates, but what isn't as widely known is that constructors and destructors also have an issue.The reason that breakpoints in constructors often fail is that g++ (actually, any C++ compiler I know of) creates multiple copies of a constructor or destructor under most circumstances (the so-called in-charge and not-in-charge cases, depending on whether the complete object is being constructed or it's only the base of a derived class), likewise the destructor (whether it's a delete call or not). The result is that there are two code positions associated with the same source line. Ideally, when you set a breakpoint based on a source line, gdb would put a breakpoint in all code positions matching this source line. Instead, it arbitrarily chooses one.
|
|||||||||||||