From: "Eli Zaretskii" <eliz@gnu.org>
To: jjohnstn <jjohnstn@redhat.com>
Cc: Ulrich.Weigand@de.ibm.com, gdb-patches@sources.redhat.com
Subject: Re: [RFC]: x86 threaded watchpoint support [2/3]
Date: Thu, 17 Jun 2004 04:24:00 -0000 [thread overview]
Message-ID: <7494-Thu17Jun2004072027+0300-eliz@gnu.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0406161722440.7927-100000@tooth.toronto.redhat.com> (message from jjohnstn on Wed, 16 Jun 2004 17:39:28 -0400 (EDT))
> Date: Wed, 16 Jun 2004 17:39:28 -0400 (EDT)
> From: jjohnstn <jjohnstn@redhat.com>
>
> Actually, I believe this patch needs to be reworked. It is causing a
> failure for ia64 watchpoints. There are a number of problems to be looked
> at. First of all, the stopped_by_watchpoint flag only gets set if
> HAVE_CONTINUABLE_WATCHPOINT is true. Thus, any platform that doesn't
> define this macro or have the low level target
> to_have_continuable_watchpoint value set, will never set the
> stopped_by_watchpoint flag. The logic in
> bpstat_stop_status ignores all hardware watchpoints if the flag is not set
> so we never do the value comparison.
>
> Another problem is that some watchpoints are stepped (i.e. the signal
> occurs before the value is actually changed). When we step over the
> watchpoint, again the flag won't get set because we have actually trapped
> due to a step operation, not a watchpoint.
Can you suggest a patch to take care of these problems?
> Knowing at least one watchpoint triggered is not enough detail. Gdb then
> has to check all values for change.
If all the platform does is tell us that _some_ watchpoint breaks,
what else can we do?
> We may not stop all threads until multiple watchpoints change.
This should produce several more SIGTRAPs, one each for every
watchpoint that triggers in between. Can we somehow find out there
are several more SIGTRAPs pending, and what threads have them pending?
If not, I again don't see how can GDB do better in this situation.
Sounds like some help from the kernel is in order.
next prev parent reply other threads:[~2004-06-17 4:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-15 15:22 Ulrich Weigand
2004-06-16 21:39 ` jjohnstn
2004-06-17 4:24 ` Eli Zaretskii [this message]
2004-06-17 19:47 ` Jeff Johnston
-- strict thread matches above, loose matches on Subject: below --
2004-06-14 14:07 Ulrich Weigand
2004-06-11 21:33 Jeff Johnston
2004-06-12 9:42 ` Eli Zaretskii
2004-06-14 21:40 ` Jeff Johnston
2004-06-15 4:23 ` Eli Zaretskii
2004-06-15 12:22 ` 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=7494-Thu17Jun2004072027+0300-eliz@gnu.org \
--to=eliz@gnu.org \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jjohnstn@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