pending/1163: GDB's breakpoint internals

[Andrew Cagney <ac131313 at redhat dot com>]

>Number:         1163
>Category:       pending
>Synopsis:       GDB's breakpoint internals
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   unknown
>Arrival-Date:   Mon Mar 31 06:08:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        
>Organization:
>Environment:
>Description:
 (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
 
 
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: