From: Pedro Alves <pedro@codesourcery.com>
To: "Ulrich Weigand" <uweigand@de.ibm.com>
Cc: Thiago Jung Bauermann <bauerman@br.ibm.com>,
Eli Zaretskii <eliz@gnu.org>,
gdb-patches@sourceware.org
Subject: Re: [RFA 2/3] Demote to sw watchpoint only in update_watchpoint
Date: Thu, 05 May 2011 15:21:00 -0000 [thread overview]
Message-ID: <201105051621.42627.pedro@codesourcery.com> (raw)
In-Reply-To: <201105051110.p45BA6Jm013405@d06av02.portsmouth.uk.ibm.com>
On Thursday 05 May 2011 12:10:05, Ulrich Weigand wrote:
> Pedro Alves wrote:
> > On Wednesday 04 May 2011 23:20:48, Thiago Jung Bauermann wrote:
> > > Pedro's suggestion:
> > >
> > > 1. The inferior is stopped and software bp_locations (both breakpoints
> > > and watchpoints) are removed. Hardware ones stay in place.
> > > 2. The user asks for a new watchpoint.
> > > 3. GDB evaluates the expression and creates the bp_locations.
> > > 4. GDB tries to insert the bp_locations as hw watches. If that fails,
> > > then converts to sw and registers the watchpoint for insertion.
> > > 5. The user asks the inferior to be continued.
> > > 6. GDB inserts sw breakpoints and watchpoints and resumes the inferior.
> >
> > Either that or try keep hardware breakpoints and watchpoints uninserted,
> > and insert them just before 4. This variant is a bit safer in case GDB crashes,
> > but is a bit less efficient in case there are many watchpoints. But then
> > again we already remove/insert them all at each step, so that is kind of moot.
> > I've no real preference on which. This is a minor detail in the grand scheme
> > from my perspective.
>
> One thing I'm wondering about is the comment before update_watchpoints:
>
> Even with `set breakpoint always-inserted on' the watchpoints are
> removed + inserted on each stop here Normal breakpoints must
> never be removed because they might be missed by a running thread
> when debugging in non-stop mode. On the other hand, hardware
> watchpoints (is_hardware_watchpoint; processed here) are specific
> to each LWP since they are stored in each LWP's hardware debug
> registers. Therefore, such LWP must be stopped first in order to
> be able to modify its hardware watchpoints.
> [etc.]
>
> Is this still valid, and would it affect this current discussion if so?
This is stale. Watchpoints are no longer removed/inserted
on each stop with always-inserted on. It needed fixing for watchpoints+non-stop.
linux gdbserver copes with inserting breakpoints/watchpoints when
threads are running. Native linux doesn't, but that just it doesn't really
fully support watchpoints in non-stop mode currently.
--
Pedro Alves
next prev parent reply other threads:[~2011-05-05 15:21 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
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 [this message]
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=201105051621.42627.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