From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: drow@mvista.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] Fix watchpoints when stepping over a breakpoint
Date: Fri, 05 Apr 2002 08:45:00 -0000 [thread overview]
Message-ID: <9743-Fri05Apr2002194115+0300-eliz@is.elta.co.il> (raw)
In-Reply-To: <20020405105416.A14105@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 5 Apr 2002 10:54:16 -0500)
> Date: Fri, 5 Apr 2002 10:54:16 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> >
> > Isn't this a bit ad hoc? I think the issue of doing TRT when both a
> > breakpoint and a watchpoint fire for the same instruction needs a more
> > general solution. While ignoring breakpoints might be the Right Thing
> > in this particular case, I wonder what will be TRT in other cases?
> >
> > Did you try to arrange for a normal breakpoint and a watchpoint on the
> > same instruction, and see what happens in that case, with and without
> > this patch?
>
> Yes, I did - that's 'watch a.x' in gdb.c++/annota2.exp. Without the
> patch it fails on i386-linux, with it it passes.
``Fails'' and ``passes'' are in the eyes of the beholder ;-)
I mean, I'm not even sure what is the ``right'' behavior in this case.
The annota2.exp test expects something very specific, but is that what
we want? Perhaps GDB should say that both breakpoint and watchpoint
fired instead, or do something else?
I'd suggest to discuss this a bit, because otherwise I don't even know
what are the criteria for approving or rejecting the patch. The mere
fact that the number of testsuite failures goes down is not enough,
IMHO.
> I don't really think it's any more ad-hoc than the trap_expected flag.
Perhaps not, but that doesn't mean we should proliferate ad-hoc'ery.
More importantly, an introduction of a general-purpose mechanism to
ignore breakpoints is something that I consider to be dangerous,
because it is no longer limited to special situations such as
single-stepping.
next prev parent reply other threads:[~2002-04-05 16:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-02 15:43 Daniel Jacobowitz
2002-04-04 23:38 ` Eli Zaretskii
2002-04-05 7:54 ` Daniel Jacobowitz
2002-04-05 8:45 ` Eli Zaretskii [this message]
2002-04-05 9:08 ` Daniel Jacobowitz
2002-04-05 9:55 ` Andrew Cagney
2002-04-05 23:48 ` Eli Zaretskii
2002-04-06 7:36 ` Daniel Jacobowitz
2002-04-06 9:21 ` Eli Zaretskii
2002-04-06 9:49 ` Daniel Jacobowitz
2002-04-07 9:16 ` Andrew Cagney
2002-04-07 10:03 ` Eli Zaretskii
2002-04-14 14:49 ` Andrew Cagney
2002-04-14 22:07 ` Eli Zaretskii
2002-04-18 18:34 ` Andrew Cagney
2002-04-02 22:18 Michael Elizabeth Chastain
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=9743-Fri05Apr2002194115+0300-eliz@is.elta.co.il \
--to=eliz@is.elta.co.il \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.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