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

[Elena Zannoni <ezannoni at redhat dot com>]

Michael Snyder writes:
 > 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.
 > 
 > 
 > 


The CLI needs to provide information in at least 3 cases, that I can
think of.

1. insert the breakpoint, show confirmation to the user. If we have 20
   'real' breakpoints inserted, what do we tell the user? 

2. hit the breakpoint, show line info about where we stopped, and
   breakpoint number. Do we just say the program hit the high level
   breakpoint number, or also which low level breakpoint number? Hmm,
   do low level breakpoints have numbers? (I can see that we kind of
   need a pair of numbers now).

3. list the breakpoints (info break) Ok, this we kind of discussed.



And MI? what should we do there? the same 3 cases occur.  I would
think that MI could just tell the gui everything every time, and then
the GUI could decide to display what it wants.  However that's a lot
of information sent back and forth, maybe for no real advantage. So
maybe a two-tier command set is needed there too.  Depending on which
'view' the gui is in (I can imagine a gui having 2 views, one which
shows all the hidden bps, and one that shows only the high level
ones), or in general depending on what it wants to display it would
send different commands to gdb/MI.

elena