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