suggestion for auto breakpoints

[Petr Sorfa]

Hi Duane,

> > > A useful way to debug new programs is to place a break point
> > > inside each function and even inside each if/else and switch
> > > statement.
> >
> > This would be too much work, and I doubt that you'll use this feature,
> > especially as the complexity of your app increases. Finding all the places to
> > set breakpoints would require parsing your source, and I don't want the
> > debugger to be involved in that.
> 
> I agree the debugger should not do it.  "some" part of kdevelop however
> already does parse the source (to create the list of functions).
> Creating
> a list of tags for complete breakpoint coverage here should be pretty
> straight forward.?
Actually, GDB (and other debuggers) provide a facility of listing
functions, etc.. in the current debugged process. In addition to that
debuggers can handle dynamic libraries and programs/libraries that there
is no source code for. Since the capabilities already exist, just query
the debugger and grab the list. I think it might be possible to update
the list if a dynamic library is pulled in.

The major difference between source code parsing and the information
from a debugger, is that the former should work on code that might not
compile, whilst the latter on code that has already compiled.

But ultimately, by making the code parser better, will make kdevelop
better.

Petr
> > In a medium size app, written by a team of
> > people, you could easily be looking at a few thousand breakpoints. A
> > daunting task for a single person to check every path.
> 
> Yes, as is ensuring that each code path is debugged - or even gets
> executed.  With a list of these breakpoints which are persistent
> across invocations of kdevelop, the team would, after a group debug
> effort, be left with a list of places where execution never, or
> rarely occurs.  These are the places most prone to bugs.
> 
> > There is a way for you to do this now, but it involves you writing some code.
> 
> I was hoping for some automation help.  ;)
> 
> And the code verification people might all be beside themselves with
> interest.
> 
> > Add a debug function which calls another function that is called only once
> > per run and set the breakpoint on this. Then sprinkle the debug calls throughout
> > your program.
> 
> . with one flag per debug call..  which is what a breakpoint is.
> 
> > If, after "prototyping" this functionality in your app, you still feel it's
> > valuable then perhaps I could be persuaded.
> 
> Well let's keep it out of the debugger and see if the code parser folks
> are interested.  This may help solve their current "sliding breakpoints"
> bug too.

-- 
--------------------------------------------------------
Petr Sorfa                  Software Engineer
Santa Cruz Operation (SCO)  
--------------------------------------------------------
Disclaimer: All my comments are my own and nobody else's
----------------------------------------------------------