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

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

[Jim Ingham]

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

Jim

On Wednesday, March 26, 2003, at 11:03  AM, 
gdb-digest-help@sources.redhat.com wrote:

>
> (Put simply, the things you learn when reading a book explaining how a 
> debugger should work :-)
>
> The `How Debuggers Work' [rosenberg] book describes a breakpoint 
> implementation broken into two parts:
>
> - high level user breakpoint list
> This is what the user sees.  One entry corresponds to each `break XXX' 
> command.  That high level breakpoint then maps onto 1 or more ...
>
> - low level physical breakpoints (or watchpoints or ...)
> One entry per physical breakpoint.  When a breakpoint is hit, a 
> reverse map back to each high-level breakpoint for the event is done, 
> and then that breakpoint's handler is called.
>
> I might be mistaken, but I don't think GDB implemented things this 
> way.  Instead, it has a single tangled table.
>
> Andrew
>
>
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

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

[Andrew Cagney]

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

Andrew

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

[Andrew Cagney]

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

For instance, they could be offered:

Set breakpoint at ...
<template a::foo>FileFullOfTemplates.hh:27?
<template b::foo>FileFullOfTemplates.hh:27?
<template c::foo>FileFullOfTemplates.hh:27?
<template d::foo>FileFullOfTemplates.hh:27?

But also:

Set breakpoint at ...
<template a>FileFullOfTemplates.hh:27, inlined at b.cc:27?
<template a>FileFullOfTemplates.hh:27, inlined at b.cc:28?
<template a>FileFullOfTemplates.hh:27, inlined at b.cc:29?
....

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.

Andrew

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

[Daniel Jacobowitz]

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

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

[Andrew Cagney]

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

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

Andrew

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

[Daniel Jacobowitz]

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

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

[Andrew Cagney]

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

yes.

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

It does, but it `paints with a broad brush'.  Don't expect a technical 
cook book.  Rather something that sets a good direction and identifies 
the basic issues.

I think you already know: breakpoint on an in-line function means 
finding all instances and then adding a physical breakpoint for each.

Andrew

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

[Jim Ingham]

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