suggestion for auto breakpoints

[Petr Sorfa]

Hi Bernd,

> >> >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.
> >>
> >> That's what gprof was made for.
> >Correct, but not to this level. For instance, the execution flow can be
> >interactive (in fact all the data can be controlled while the program is
> >executing). Also you actually do not have to generate profiled code.
> >
> >For instance you could have a list of selected functions that turn a
> >different colour based on their call frequency in relation to other
> >functions in real time. Think of something like top or sar, but for
> >function calls rather than system resources/processes.
> 
> Well, the number of function calls is a quite irrelevant quantity.
> For performance tuning, timing is much more important. And for timing,
> it is important that the timing routine doesn't influence the program
> flow too much. When every breakpoint must go through the whole gdb,
> code, then its output routine, the pipe to KDevelop, the parsing
> routine and then some more stuff, you can forget to obtain any
> meaningful information. And for code coverage analysis, using an
> automated testing framework around gcov is much smarter than watching
> things happen on the monitor. You can store the obtained data for later
> retrieval, send them to others by e-mail and work with scripts on them.
You are right of course. Profiling in this manner (execution times and
so on) is not a good idea. The transfer of data between the debugger and
kdevelop is also a valid point. However, code coverage done by the
debugger is much easier for the pure fact that you don't have to use any
other tool. On gcov's side, is that it does exist whilst this debugger
feature does not.

Going with John's (jbb) suggestion it might be a better idea to provide
some kind of interface in kdevelop for these other tools (gprof, gcov
and friends) and possibly use the debugger for some features that are
not covered by the others.

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