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

[Elena Zannoni <ezannoni@redhat.com>]

Daniel Jacobowitz writes:
 > On Thu, Oct 16, 2003 at 08:54:05AM +0200, Eli Zaretskii wrote:
 > > > From: Elena Zannoni <ezannoni@redhat.com>
 > > > Date: Wed, 15 Oct 2003 15:07:41 -0400
 > > > 
 > > > 1. insert the breakpoint, show confirmation to the user. If we have 20
 > > >    'real' breakpoints inserted, what do we tell the user? 
 > > 
 > > If we can guess the one address which is what the user wants to see in
 > > the current context, let's show that single address.  Otherwise, let's
 > > either show all of them or none at all, perhaps controlled by some
 > > user option.
 > 
 > Seems reasonable.
 > 

sounds ok to me.

Just occurred to me that maybe the user sometimes would want to set a
breakpoint in just one particular instance of an inlined function, we
should still allow that. I.e. should setting the multiple breakpoints
be the default?



 > > > 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?
 > > 
 > > I'd say we show the high-level number and the precise machine address
 > > where it breaks.
 > 
 > Right now we show the breakpoint address for breakpoints which are not
 > at the beginning of a source line, and just the breakpoint and line
 > numbers for breakpoints which are at the beginning of a line.  How
 > would this interact with that?  Show the address always, or for
 > breakpoints which either are in the middle of a line or in multiple
 > locations?
 > 

Maybe we should show 'Breakpoint 5.3' and then use the same rule we
have now to decide whether to show the line or the address. This way
the user knows which high level bp was hit.  How a gui is going to
represent that, it's beyond me. 

 > > >    Hmm, do low level breakpoints have numbers?
 > > 
 > > I don't think we need numbers for them, so let's not have them.
 > 
 > I actually think that we do need numbers for them.
 > 
 > My hypothetical use case is something like this:
 > (gdb) break inline_foo
 > Breakpoint 5 set at inline_foo, which has multiple locations.
 > Say "info breakpoint 5" for more details.
 > (gdb) info break 5
 > Num Type          Enb Address    What
 > 1   sw breakpoint  y  0x8040222  inlined into foo
 > 2   sw breakpoint  y  0x8040822  inlined into bar
 > 3   sw breakpoint  y  0x8040852  inlined into boring_loop
 > (gdb) disable 5.3
 > (gdb) run
 > 

Yes, I was thinking something like that too. Even though, there should
probably be a 5 somewhere in the output of info break.

 > I am not sure about "delete 5.3", though - that makes tracking which
 > breakpoints have been set a little trickier, for not much gain.
 > 

Maybe delete could be implemented internally as mark the child
breakpoint as deleted, instead of removing it from the list. Similar
to disabling it but the user will not be able to access it ever again.

 > > > 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.
 > > 
 > > Probably.
 > > 
 > > > 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.
 > > 
 > > Yes, probably.
 > 
 > These make sense to me also.
 > 

I'd like to hear from MI users otherwise we'll be designing in a vacuum.
I'll send something to the eclipse folks.

elena


 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer