Re: gdb Digest 26 Mar 2003 19:03:48 -0000 Issue 1129

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Mar 28, 2003 at 06:13:10PM -0500, Andrew Cagney wrote:
> >>Andrew,
> >>
> >>Addressing this problem - driven by the needs of C++ developers - is 
> >>something I was lobbying for time to do during this release cycle.  But 
> >>it got put off in favor of solving performance issues in gdb instead.  
> >>However, for the next one (starting post June) release cycle I will 
> >>probably get more time to look at this.
> >>
> >>I don't think we can just hide the physical breakpoints from the user 
> >>however.  It would be very useful to be able to say
> >>
> >>(gdb) break FileFullOfTemplates.cc:27
> >>
> >>then decide that "no you weren't interested in the int specialization 
> >>only the double one", or whatever...  So being able to peer into the 
> >>contents of the user-lever breakpoint is a good thing.  OTOH, I should 
> >>certainly be able to disable this breakpoint and not hit it for any 
> >>variant...
> >>
> 
> >True.  Being able to manipulate the mapping will also be useful.
> 
> brain enganges.  It's more complicated.  If I understand this correctly.
> 
> (gdb) break FileFullOfTemplates.hh:27
> 
> The user might mean:
> 
> - the line number
> - a template instance
> - all inline function instances
> - (I'm sure there is more)

Right.  The big thing this means is that we need to think about the
interface.  Asking isn't a real option.  For instance, in the Linux
kernel, if you break on (say) i386's inlined get_current function - if
we could ever handle that - there'd probably be millions of locations.
This requires:
  - scaling the implementation; if we remove a million breakpoints at
    every stop then we're going to lose.
  - scaling the interface; if we ask a million questions the user will
    give up.

> Either way, I think these are high-level table entries.  The user could 
> certainly view the mapping:
> 
> maint print breakpoint
> Breakpoint 1 <template a::foo>FileFullOfTemplates.hh:27 at
> 0x123 (b.cc:27), 0x234 (b.c:28), ...
> 
> but the manipulation would still typically be high level.

This suggests that we need three levels then.

Does anyone know how other debuggers handle this?  I'm sure we're not
the first but it's been ages since I used a non-GDB debugger for
anything.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer