This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 at apple dot com
Developer Tools
Apple Computer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]