Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder <msnyder at redhat dot com>]

Andrew Cagney wrote:
> > If this is just an internals issue, then toss a coin, it
> > doesn't matter.  But for the picture that we present to the
> > user, remember -- we always present a fictional picture that
> > hides most of the underlying details.  The unsophisticated
> > user thinks he is debugging his code -- not the underlying
> > machine.  If possible, he doesn't want to know eg. that
> > line seventeen has been broken into several locations and
> > intermixed with code from 3 other lines.  We're sometimes
> > forced to tell him anyway, but we don't if we can avoid it.
>
>
> Yes, it is user visible (which is why people are also looking for a 
> user-level command, different to "maint info break" and "info break", 
> that displays both the logical and physical breakpoint).

Yep.  Didn't mean to imply that it wasn't user visible.

> With a GUI, I can see each logical breakpoint having an expand widget 
> (correct technical term is?) that lets the user see (modify?) the 
> underlying physical breakpoint list.

Yep, pretty much what I had in mind.  For the cli interface
I would hope for something similar -- something that initially
displayed only the "high level" breakpoints, but maybe with an
asterisk or something to indicate that there was more to the
picture if one wanted to know.  And some syntax equivalent to
clicking on the GUI expand widget, which could be a variation
on an existing command, or a new command (I have no preference).


> This is needed, as otherwize something apparently simple "break strcmp" 
> could result in the user unknowingly setting 1000's of breakpoints.

That's true as it is -- I guess what we have now is that
pop-up menu that says "Which one of these did you mean?"
I presume that when that interface was implemented, we
did not expect it to come up all that often.  Now, with
overloaded functions, templates, weird constructors and
so forth, we anticipate that it will come up more often,
so we need a less intrusive interface.