suggestion for auto breakpoints

[Duane Voth]

> > Well, the number of function calls is a quite irrelevant quantity.
> > For performance tuning, timing is much more important.

Petr adds:
> 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.

Agreed.  Clearly code coverage and profiling have very different foci.
We would want to provide separate menu entries at the kdevelop
level seeing as the gui should be task oriented instead of
implementation oriented.  I.e.

          Tools -> code coverage
          Tools -> profiling

Actually I think code coverage is more a debug feature.  Set/Clear
multiple breakpoints look better under the Debug menu...

          Debug -> clear all breakpoints
          Debug -> set code coverage breakpoints

but I am getting ahead of things!

> 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.

If coverage of functions is all that we are interested in then the
function list (from the debugger?) is fine.  But if we are interested
in covering branches, then the debugger doesn't seem like the right
tool to provide breakpoint data.  Is it interesting that gcov is aware
of branches:

	http://www.dis.com/gnu/gcc/gcc_114.html#SEC115

duane