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

[Jim Ingham <jingham at apple dot com>]

On Oct 16, 2003, at 9:17 AM, gdb-patches-digest-help@sources.redhat.com 
wrote:

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

I think in all cases the UI will want to know about the multiple hits.

One case that would be very useful is a single breakpoint that turns 
into many logically distinct entities.  For instance, breaking on a 
file & line in a template function or class method turns into 
breakpoints on all the instantiations of that template function/method. 
 In this case the GUI really would be interested in this, since it 
would be useful to display these choices to the user and have her pick 
which ones she actually wants.

The other is where the multiple breakpoints are not really distinct.  
An example of this is breaking on an inlined function.  Without 
expanding inlined calls in the source view of the call sites, knowing 
where all the breakpoints are in source view is not terribly helpful.  
But if somebody switches to Assembly view, we had better show them the 
breakpoints that have been set or they will get very confused...

So I think we do need them.

Our experience with MI is that as long as the information dump is not 
too large, multiple round trips are more expensive than lots of info.  
Parsing the MI output is pretty quick.  I bet if we start getting 
~1000's of breakpoints the time gdb spends finding all the instances 
will swamp the time it takes to ship them across the pipe...  So my 
guess is that doing it simply and just telling the user about all the 
breakpoints as they are set is okay.

The one thing we do need to be careful about is to not reset all the 
breakpoints in all the shared libraries each time a new one is loaded.  
This is the current gdb behavior, but it will quickly get very 
inefficient as the number of shared libraries & breakpoints therein 
increase.  It is pretty easy to get around this with a little judicial 
hacking, however.

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer