suggestion for auto breakpoints

[Petr Sorfa]

Hi John,

I think the idea may have its merits. The problem is to determine
whether it needs to be developed at kdevelop level or at the debugger
(gdb) level. There are hidden joys of this. You can trace program
execution, function call count, function time usage and other uses.
Coupled with kdevelop, we could produce nice little graphs of hot areas
and so on. It would impact program performance though under kdevelop and
as long as these breakpoints can be hidden from the user then it should
be ok. Basically these breakpoints should be marked differently from the
standard breakpoints.

Petr

> On Wed, 02 Feb 2000, you wrote:
> > 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 can create quite a few break points but with
> > awesome development tools like kdevelop, tracing through each
> > path of an entire program becomes a reasonable task - AND it
> > allows for some of the best code verification testing we've
> > ever had.
> >
> > What is great is that (once the breakpoint/line number tracking
> > problem is fixed) the breakpoints will tend to linger around
> > until the developer specifically turns each one off allowing
> > the tools to track which lines of code have not been executed
> > and checked.
> >
> > How about an option per function, file, or project that would
> > add breakpoints in such a fashion? (configurable as to stopping
> > for branch statements of course)  Imo, a menu item "Set multiple
> > breakpoints" could go right above "Clear all breakpoints" (which
> > btw is immediately useful!) and provide a sub menu for function,
> > file, or project.
> >
> > comments?
> >
> > duane
> 
> Hi,
> 
> 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. 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. I've also never felt the
> need for this type of functionality, and I've been debugging programs for too
> many years now, but I could be wrong :-)
> 
> There is a way for you to do this now, but it involves you writing some code.
> 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. Not exactly the same, but it'll give you a better idea as to
> whether this would be really useful or not.
> 
> If, after "prototyping" this functionality in your app, you still feel it's
> valuable then perhaps I could be persuaded. Now if you create a patch that does
> this, well...
> 
> There are some other features a bit along these lines that I'd like to do
> though.
> set breakpoints matching a regular expression.
> set catch points.
> 
> not to mention the very basic
> set breakpoint on function name
> set breakpoint on address
> 
> --
> Regards,
> 
> jbb
> http://homepages.ihug.co.nz/~jbb
> ICQ: 60412209

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