From: Eli Zaretskii <eliz@gnu.org>
To: Thiago Jung Bauermann <bauerman@br.ibm.com>
Cc: uweigand@de.ibm.com, gdb-patches@sourceware.org
Subject: Re: [RFA 2/3] Demote to sw watchpoint only in update_watchpoint
Date: Wed, 04 May 2011 20:31:00 -0000 [thread overview]
Message-ID: <83pqnymcng.fsf@gnu.org> (raw)
In-Reply-To: <1304536344.19357.218.camel@hactar>
> From: Thiago Jung Bauermann <bauerman@br.ibm.com>
> Cc: uweigand@de.ibm.coma, gdb-patches@sourceware.org
> Date: Wed, 04 May 2011 16:12:24 -0300
>
> GDB doesn't have a command to create a hardware watchpoint or a software
> watchpoint. It will decide which will be created based on what it thinks
> can be done. Do you think this should be changed and there should be an
> hwatch command which would fail if an hw watchpoint is not possible? Or
> just that a watchpoint should never be converted between sw and hw after
> they are created?
It certainly is bad to have the demotion happen when you resume the
inferior. Pedro's suggestion resolves this as well, because the
problem will be revealed at "watch foo" time. If and when we
implement that, there will be no need for "hwatch", I think, as the
user will see the problem on the spot and can take corrective actions
in time.
> So the problem is still there. It's not better, but not worse either.
> The output is slightly different because of the better error handling
> this patch introduces. Thus, IMHO overhauling resources handling is not
> a prerequisite or even directly related to this patch (or the next one
> in the series). The acceptance or rejection of this patch is orthogonal
> to that.
Fair enough. I withdraw my objections to the patch.
> Having said that, I agree that it's a shame that GDB can't keep track of
> debug hardware availability, something that one would expect to be among
> the basic tasks of a debugger. So if we can agree on how GDB should deal
> with the problem, I'm willing to work on it on a best effort basis
> (meaning that I wouldn't have much time to dedicate to this, but would
> eventually make progress).
Thank you. I think Pedro's idea is already on the table, and no one
objected to it. If it is feasible, I'd say let's do it that way.
next prev parent reply other threads:[~2011-05-04 20:31 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-13 20:55 [RFA] Implement support for PowerPC BookE masked watchpoints Thiago Jung Bauermann
2011-01-31 20:09 ` Thiago Jung Bauermann
2011-02-17 15:10 ` Ulrich Weigand
2011-04-18 21:22 ` [RFA 2/3] Demote to sw watchpoint only in update_watchpoint Thiago Jung Bauermann
2011-04-29 17:26 ` Ulrich Weigand
2011-05-03 4:56 ` Thiago Jung Bauermann
2011-05-03 6:05 ` Eli Zaretskii
2011-05-03 9:58 ` Pedro Alves
2011-05-03 16:57 ` Eli Zaretskii
2011-05-03 17:41 ` Pedro Alves
2011-05-03 18:03 ` Eli Zaretskii
2011-05-03 18:12 ` Pedro Alves
2011-05-03 20:30 ` Eli Zaretskii
2011-05-04 0:03 ` Thiago Jung Bauermann
2011-05-04 3:07 ` Eli Zaretskii
2011-05-04 22:21 ` Thiago Jung Bauermann
2011-05-05 3:09 ` Eli Zaretskii
2011-05-05 8:15 ` Pedro Alves
2011-05-05 10:28 ` Eli Zaretskii
2011-05-05 15:27 ` Pedro Alves
2011-05-05 16:27 ` Eli Zaretskii
2011-05-05 11:10 ` Ulrich Weigand
2011-05-05 15:21 ` Pedro Alves
2011-05-04 19:12 ` Thiago Jung Bauermann
2011-05-04 20:31 ` Eli Zaretskii [this message]
2011-05-04 22:22 ` Thiago Jung Bauermann
2011-05-05 11:04 ` Ulrich Weigand
2011-04-18 21:22 ` [RFA 1/3] Change watchpoint's enable state in do_enable_breakpoint Thiago Jung Bauermann
2011-04-29 17:21 ` Ulrich Weigand
2011-05-04 0:11 ` Thiago Jung Bauermann
2011-04-18 21:24 ` [RFA 3/3] Implement support for PowerPC BookE masked watchpoints Thiago Jung Bauermann
2011-04-29 17:46 ` Ulrich Weigand
2011-05-03 4:56 ` [needs doc review] " Thiago Jung Bauermann
2011-05-03 6:24 ` Eli Zaretskii
2011-05-05 21:57 ` Thiago Jung Bauermann
2011-05-06 10:28 ` Eli Zaretskii
2011-05-06 20:35 ` Thiago Jung Bauermann
2011-05-05 11:07 ` Ulrich Weigand
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=83pqnymcng.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=bauerman@br.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=uweigand@de.ibm.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