* Re: gdb Digest 26 Mar 2003 19:03:48 -0000 Issue 1129 [not found] <1048705428.15342.ezmlm@sources.redhat.com> @ 2003-03-26 19:37 ` Jim Ingham 2003-03-28 22:49 ` Andrew Cagney 0 siblings, 1 reply; 8+ messages in thread From: Jim Ingham @ 2003-03-26 19:37 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb Digest 26 Mar 2003 19:03:48 -0000 Issue 1129 2003-03-26 19:37 ` gdb Digest 26 Mar 2003 19:03:48 -0000 Issue 1129 Jim Ingham @ 2003-03-28 22:49 ` Andrew Cagney 2003-03-28 23:13 ` Andrew Cagney 0 siblings, 1 reply; 8+ messages in thread From: Andrew Cagney @ 2003-03-28 22:49 UTC (permalink / raw) To: Jim Ingham; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb Digest 26 Mar 2003 19:03:48 -0000 Issue 1129 2003-03-28 22:49 ` Andrew Cagney @ 2003-03-28 23:13 ` Andrew Cagney 2003-03-28 23:56 ` Daniel Jacobowitz 0 siblings, 1 reply; 8+ messages in thread From: Andrew Cagney @ 2003-03-28 23:13 UTC (permalink / raw) To: Jim Ingham; +Cc: gdb >> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb Digest 26 Mar 2003 19:03:48 -0000 Issue 1129 2003-03-28 23:13 ` Andrew Cagney @ 2003-03-28 23:56 ` Daniel Jacobowitz 2003-03-29 0:49 ` Andrew Cagney 0 siblings, 1 reply; 8+ messages in thread From: Daniel Jacobowitz @ 2003-03-28 23:56 UTC (permalink / raw) To: Andrew Cagney; +Cc: Jim Ingham, gdb 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb Digest 26 Mar 2003 19:03:48 -0000 Issue 1129 2003-03-28 23:56 ` Daniel Jacobowitz @ 2003-03-29 0:49 ` Andrew Cagney 2003-03-29 0:58 ` Daniel Jacobowitz 0 siblings, 1 reply; 8+ messages in thread From: Andrew Cagney @ 2003-03-29 0:49 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Jim Ingham, gdb > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb Digest 26 Mar 2003 19:03:48 -0000 Issue 1129 2003-03-29 0:49 ` Andrew Cagney @ 2003-03-29 0:58 ` Daniel Jacobowitz 2003-03-29 1:32 ` Andrew Cagney 2003-03-29 3:30 ` Jim Ingham 0 siblings, 2 replies; 8+ messages in thread From: Daniel Jacobowitz @ 2003-03-29 0:58 UTC (permalink / raw) To: Andrew Cagney; +Cc: Jim Ingham, gdb 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb Digest 26 Mar 2003 19:03:48 -0000 Issue 1129 2003-03-29 0:58 ` Daniel Jacobowitz @ 2003-03-29 1:32 ` Andrew Cagney 2003-03-29 3:30 ` Jim Ingham 1 sibling, 0 replies; 8+ messages in thread From: Andrew Cagney @ 2003-03-29 1:32 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Jim Ingham, gdb > > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb Digest 26 Mar 2003 19:03:48 -0000 Issue 1129 2003-03-29 0:58 ` Daniel Jacobowitz 2003-03-29 1:32 ` Andrew Cagney @ 2003-03-29 3:30 ` Jim Ingham 1 sibling, 0 replies; 8+ messages in thread From: Jim Ingham @ 2003-03-29 3:30 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Andrew Cagney, gdb 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-03-29 3:30 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1048705428.15342.ezmlm@sources.redhat.com> 2003-03-26 19:37 ` gdb Digest 26 Mar 2003 19:03:48 -0000 Issue 1129 Jim Ingham 2003-03-28 22:49 ` Andrew Cagney 2003-03-28 23:13 ` Andrew Cagney 2003-03-28 23:56 ` Daniel Jacobowitz 2003-03-29 0:49 ` Andrew Cagney 2003-03-29 0:58 ` Daniel Jacobowitz 2003-03-29 1:32 ` Andrew Cagney 2003-03-29 3:30 ` Jim Ingham
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).