RFA: Breakpoint infrastructure cleanups [0/8]

Daniel Jacobowitz drow@mvista.com
Thu Oct 16 13:11:00 GMT 2003


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.

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

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

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

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer



More information about the Gdb-patches mailing list