From: Mark Salter <msalter@redhat.com>
To: eliz@is.elta.co.il
Cc: kettenis@science.uva.nl, msnyder@cygnus.com,
gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: Make Linux use the new unified x86 watchpoint support
Date: Tue, 27 Mar 2001 10:58:00 -0000 [thread overview]
Message-ID: <200103271350.f2RDoeY17397@deneb.localdomain> (raw)
In-Reply-To: <Pine.SUN.3.91.1010327121330.21272I-100000@is>
>>>>> Eli Zaretskii writes:
> On Tue, 27 Mar 2001, Mark Kettenis wrote:
>> Except that the implementation of hardware breakpoints/watchpoints in
>> core GDB is really shoddy.
> True. It clearly shows that it was originally written for a very special
> platform (Sparclet, I think) and was designed accordingly. Certain
> aspects of how breakpoint.c handles watchpoints cannot be understood
> without having this in mind. For example, why on Earth are
> software watchpoints and hardware watchpoints handled differently from
> read and access watchpoints? why are hardware breakpoints treated like
> normal breakpoints instead of being akin to watchpoints? etc., etc.
Not just shoddy, but plain broken for a number of targets.
When a read wathcpoint is triggered, the target stops and informs gdb.
In breakpoint.c, gdb sees that there are read or access watchpoints set
and that the data address reported by the target matches. This causes
watchpoint_check() to be called. The problem is that watchpoint_check()
will try to read from the watched data area to see if it changed, but
this is done before gdb has removed watchpoints from the target. This
causes the target to respond with an error when gdb tries to access the
watched area.
--Mark
next prev parent reply other threads:[~2001-03-27 10:58 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-21 18:47 Mark Kettenis
2001-03-26 18:14 ` Michael Snyder
2001-03-27 0:46 ` Mark Kettenis
2001-03-27 8:45 ` Michael Snyder
2001-04-17 17:26 ` Michael Snyder
2001-04-17 23:58 ` Mark Kettenis
2001-03-26 18:35 ` Michael Snyder
2001-03-26 22:57 ` Eli Zaretskii
2001-03-27 1:13 ` Mark Kettenis
2001-03-27 1:31 ` Eli Zaretskii
2001-03-27 2:09 ` Mark Kettenis
2001-03-27 2:20 ` Eli Zaretskii
2001-03-27 10:58 ` Mark Salter [this message]
2001-03-28 1:19 ` Eli Zaretskii
2001-03-28 5:10 ` Mark Salter
2001-03-28 5:39 ` Eli Zaretskii
2001-03-28 8:06 ` Mark Salter
2001-03-29 12:06 ` Eli Zaretskii
2001-03-29 12:03 ` Mark Salter
2001-03-27 8:55 ` Michael Snyder
2001-03-27 9:46 ` Eli Zaretskii
2001-03-27 9:55 ` Fernando Nasser
2001-03-27 11:59 ` Michael Snyder
2001-03-27 12:04 ` Fernando Nasser
2001-03-27 11:58 ` Michael Snyder
2001-03-28 1:31 ` Eli Zaretskii
2001-03-28 2:03 ` Mark Kettenis
2001-03-27 8:52 ` Michael Snyder
2001-03-27 15:51 ` Mark Kettenis
2001-03-27 10:03 ` Andrew Cagney
2001-03-27 8:48 ` Michael Snyder
2001-03-27 9:43 ` Eli Zaretskii
2001-03-27 11:57 ` Michael Snyder
2001-03-28 1:30 ` Eli Zaretskii
2001-03-28 11:53 ` Michael Snyder
2001-03-29 12:06 ` Eli Zaretskii
[not found] <Pine.SUN.3.91.1010329160617.4915G-100000@is>
2001-03-29 18:15 ` Mark Salter
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=200103271350.f2RDoeY17397@deneb.localdomain \
--to=msalter@redhat.com \
--cc=eliz@is.elta.co.il \
--cc=gdb-patches@sources.redhat.com \
--cc=kettenis@science.uva.nl \
--cc=msnyder@cygnus.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