This is the mail archive of the gdb-patches@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: RFA: Breakpoint infrastructure cleanups [1/8] - define impl_breakpoint


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.


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