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

[Jim Ingham <jingham@apple.com>]

Like Daniel, I can see many useful cases where folks would want to 
manipulate the lower level breakpoints in some cases.  Particularly 
templates, where you can imagine using the file:line location as the 
easiest way to specify the breakpoint (and with a GUI debugger the most 
obvious one).  Then you might want to filter the list after it is set.  
Similarly, I might want to set a breakpoint on an inlined function ONLY 
in one shlib.  So I break on the .h file, using file:line breakpoints, 
and then turn off the ones I don't want.  It would be even nicer if 
physical breakpoints knew the objfile they were set in so I could 
filter on that...

I'll try firing up Metrowerks on Monday and see what they do for 
Templates.  I KNOW it is much better than gdb, 'cause I get told so 
every couple of days :-(, but I don't know what they do yet...

Actually, it would also be nice if I could specify the objfile that the 
breakpoint is to be set in - this would be much more efficient than 
just trying it everywhere - especially when you are working under an 
IDE which KNOWS that the user set the breakpoint on a file that was 
built into the shared library foo.dylib...

Jim

On Friday, March 28, 2003, at 04:58  PM, Daniel Jacobowitz wrote:

> On Fri, Mar 28, 2003 at 07:49:42PM -0500, Andrew Cagney wrote:
>>> 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.
>>
>> Not really.
>>
>> A single user-level breakpoint would have a list of source-code
>> locations.  But those source code locations would be tightly bound to
>> that single user-level breakpoint.  It is strictly 1:N, not N:N.
>>
>> Delete the user breakpoint and you delete its list of locations.  The
>> source code locations are iterated over when adding/deleting physical
>> breakpoints to the lower-level table.
>>
>> On the other hand.  The user level breakpoint and physical breakpoint
>> tables have an N:N relationship.
>
> OK, two levels.  We still need to think about the interface for the top
> level though.  You want to be able to specify the set in some way...
>
> This sort of design is not my strong point.
>
>>> 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.
>>
>> The model I'm describing lifted from a book, the author of which was
>> involved in borland's debugger.
>
> Yes, I've heard of the book.  Does it cover things like inlined
> functions?
>
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
>
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer