suggestion for auto breakpoints

[Bernd Gehrmann]

On Thu, 03 Feb 2000 Petr Sorfa wrote:
>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.

Bernd.