Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Vladimir Prus <vladimir@codesourcery.com>
To: "Pierre Muller" <muller@ics.u-strasbg.fr>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] Clarify infrun variable naming.
Date: Fri, 23 Nov 2007 15:51:00 -0000	[thread overview]
Message-ID: <200711231851.47586.vladimir@codesourcery.com> (raw)
In-Reply-To: <006001c82de7$60649940$212dcbc0$@u-strasbg.fr>

On Friday 23 November 2007 18:41:55 Pierre Muller wrote:
> > >   But this is the reason of the failure to catch watchpoints
> > > that happen at the point where we are just stepping over a
> > breakpoint,
> > > because we step with the watchpoints disabled.
> > >   Why don't we enable all break- and watchpoints but the
> > > ones that do have the same PC we are currently?
> > 
> > Because that's extra work, and I haven't got around to that yet ;-)
> > In case of watchpoints, you probably meant enabling all watchpoint
> > at different data address, not PC?
>   Stepping over watchpoint is architechture dependent, 
> for i386 this is not needed as the watchpoint is generated with PC 
> at the instruction after the one that triggered the watchpoint... 

Yes. What I mean is that there are two situations now:

1. When we step over breakpoint, we disable everything, including watchpoints.
2. When we hit watchpoint, and the PC is at the instruction itself, we disable
all breakpoints and watchpoints when stepping.

(2) might not be a problem now, but if we wish to interact with one thread,
while others are running, it might become a problem -- other threads
might miss unrelated breakpoints and watchpoints. So, we need to:

   - Remove breakpoints at current PC
   - Remove watchpoint a the address being accessed
   - Single step

I suspect you was more interested in (1), but that's basically two sides
of the coin.

- Volodya


  reply	other threads:[~2007-11-23 15:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-23 13:23 Vladimir Prus
2007-11-23 14:53 ` Pierre Muller
2007-11-23 15:22   ` Vladimir Prus
2007-11-23 15:41     ` Pierre Muller
2007-11-23 15:51       ` Vladimir Prus [this message]
2007-11-23 16:06         ` Daniel Jacobowitz
2007-11-23 17:03           ` Vladimir Prus
2007-11-23 17:27             ` Daniel Jacobowitz
2007-11-23 16:14         ` Pierre Muller
2007-12-05  1:18 ` Jim Blandy
2007-12-05  1:52   ` Daniel Jacobowitz
2007-12-05  2:47     ` Daniel Jacobowitz
2007-12-05  8:37   ` Vladimir Prus
2007-12-05 14:13   ` Vladimir Prus
2007-12-05 21:32     ` Jim Blandy

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=200711231851.47586.vladimir@codesourcery.com \
    --to=vladimir@codesourcery.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=muller@ics.u-strasbg.fr \
    /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