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
next prev 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