Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@redhat.com>
To: Jim Blandy <jimb@redhat.com>, Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: Breakpoint infrastructure cleanups [1/8] - define impl_breakpoint
Date: Tue, 14 Oct 2003 16:03:00 -0000	[thread overview]
Message-ID: <3F8C1E65.1040702@redhat.com> (raw)
In-Reply-To: <vt23ce3fvdo.fsf@zenia.home>

> 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



  parent reply	other threads:[~2003-10-14 16:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-08 17:02 Daniel Jacobowitz
2003-10-08 18:17 ` Jim Blandy
2003-10-14  1:30   ` Daniel Jacobowitz
2003-10-14 15:31     ` Andrew Cagney
2003-10-14 15:36       ` Daniel Jacobowitz
2003-10-14 16:03   ` Andrew Cagney [this message]
2003-10-08 18:21 ` Eli Zaretskii
2003-10-08 19:11   ` Daniel Jacobowitz
2003-10-09  6:04     ` Eli Zaretskii
2003-10-09 19:16     ` Michael Snyder
2003-11-06 17:57 ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F8C1E65.1040702@redhat.com \
    --to=ac131313@redhat.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox