This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: Breakpoint infrastructure cleanups [1/8] - define impl_breakpoint
- From: Jim Blandy <jimb at redhat dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: 08 Oct 2003 13:16:03 -0500
- Subject: Re: RFA: Breakpoint infrastructure cleanups [1/8] - define impl_breakpoint
- References: <20031008170233.GA9013@nevyn.them.org>
Daniel Jacobowitz <drow@mvista.com> writes:
> +/* GDB maintains two groups of breakpoints and related events. One
> + group are the "implementation breakpoints"; these are minimal
> + structures used to manage stopping the program. They map to a specific
> + stop reason (trap at a particular PC, for instance). The other group
> + are "user breakpoints"; these carry higher-level information including
> + source locations and breakpoint conditions. */
"minimal structures used to manage stopping the program" could be
almost anything. How about:
GDB maintains two groups of breakpoints and related events. One
group are the "implementation breakpoints" (struct
impl_breakpoint); these represent specific machine-level
mechanisms used to stop the program: trap instructions patched
into the code ("software breakpoints"), hardware breakpoints,
hardware watchpoint registers, and so on.
The other group are "user breakpoints" (struct breakpoint); these
are the breakpoints as seen and manipulated by the user. They
carry higher-level information like source locations and
breakpoint conditions.
A single user breakpoint may use several implementation
breakpoints to get the right effect. For example, the GNU C++
compiler emits two copies of each constructor: the 'in-charge'
constructor and the 'not-in-charge' constructor. So a user
breakpoint on the constructor would have two separate
implementation breakpoints, one for each copy.