Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org, Eli Zaretskii <eliz@gnu.org>
Cc: bauerman@br.ibm.com, uweigand@de.ibm.com
Subject: Re: [RFA 2/3] Demote to sw watchpoint only in update_watchpoint
Date: Tue, 03 May 2011 18:12:00 -0000	[thread overview]
Message-ID: <201105031912.43042.pedro@codesourcery.com> (raw)
In-Reply-To: <83hb9b4q80.fsf@gnu.org>

On Tuesday 03 May 2011 19:02:39, Eli Zaretskii wrote:
> > The main point/win of the suggestion was avoiding the whole
> > resource accounting infrastructure, getting away without adding
> > a bunch of (what looks to me at this point, unnecessary) target
> > methods/packets/logic.
> 
> At least for x86, the resource accounting is necessary, because that
> is what allows us to have several watchpoints sharing the same debug
> register.  

Right, I meant the accounting instructure on the core side.  For
x86, i386-nat.c would stay as is.  The merging is done at insert
time currently, and it would stay the same.  The difference would
be that gdb would insert the watchpoint as soon as the user wanted
it, instead of calling some "may I create this?" mechanism.

> Targets that already have this resource accounting may well
> use it to return accurate results to target_can_use_hardware_watchpoint
> without actually going to the metal or the kernel.

I'm proposing getting rid of target_can_use_hardware_watchpoint
as being part of the core accounting infrastructure.
I'm trying to think of a use case that makes it necessary to know
if the watchpoints will fit before creating them, but I'm not
coming up with any.

-- 
Pedro Alves


  reply	other threads:[~2011-05-03 18:12 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 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: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 [this message]
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
2011-05-04 22:22               ` Thiago Jung Bauermann
2011-05-05 11:04         ` Ulrich Weigand
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=201105031912.43042.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=bauerman@br.ibm.com \
    --cc=eliz@gnu.org \
    --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