RFA: Breakpoint infrastructure cleanups [0/8]
Jim Ingham
jingham@apple.com
Thu Oct 16 18:58:00 GMT 2003
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
More information about the Gdb-patches
mailing list