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.  */

GDB users are going to need to know that breakpoints are implemented at two levels, and both of those levels will need to be visible. That's why people are suggesting pairs such as logical/physical, virtual/actual, ... Calling one "user" and the other "impl" or "machine" does not convey that implicit relationship. In fact calling one "user" is saying "hey users, just you stick to this user stuff".


``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.''

This isn't correct. The low-level breakpoints correspond to target-specific and not machine-specific mechanisms. For instance, the target can directly implement relatively abstract breakpoint/watchpoint mechanisms. Eg: per-thread breakpoints where the the underlying machine-specific mechanisms are hidden from GDB. This abstract model is extreemly common in 'debug agent' code, I've seen at least three people being forced to hack around GDB's bogus machine-level assumptions.

Andrew



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