From: Michael Chastain <mec.gnu@mindspring.com>
To: pgilliam@us.ibm.com, gdb-patches@sources.redhat.com
Cc: cagney@gnu.org
Subject: Re: [PATCH] Fixes testsuit/gdb.base/annota1.exp
Date: Thu, 23 Sep 2004 17:08:00 -0000 [thread overview]
Message-ID: <4152FD9A.nail1OT1PXJKP@mindspring.com> (raw)
In-Reply-To: <200409221910.41605.pgilliam@us.ibm.com>
I'm Trying to catch up on the thread. I'll do all the fun pontificating
here and then get to the specific revised backtrace-past-main patch in
another message.
Let's start with the delayed breakpoint message.
The actual output of gdb is:
warning: Breakpoint 3 address previously adjusted from 0x80c5a66c78 to 0x80c59643a8. ^Z^Zbreakpoint 3
That's an observed fact from gdb.log_after_bp_adjust_patch
There are two separate questions that arise from this fact:
(1) should gdb print this warning?
(2) if gdb prints this warning, is that a bug in gdb?
Part of the answer to (2) is that the test script should have a separate
arm in gdb_test_multiple for that warning. So you are on the right
track there.
The next question is what the new arm should do. It can either PASS
or KFAIL. That depends on the answer to (1). If it's okay for gdb
to print this warning, then the result should be PASS. If it's not
okay for gdb to print this warning, then the result should be KFAIL.
Sometimes you really have to hold people's feet to the fire to get
an answer to (2). People will say "it would be better if gdb did
not print XXX, but we kinda have to for now", and you have to keep
asking "gdb prints XXX. Is that a bug or not?" If you can't get
an answer, it's always safe to file a PR and KFAIL it.
If it is a KFAIL, or even if it's a PASS, it's useful to put in a
comment that recapitulates the discussion about the feature.
Something like: "this happens on ppc-64, because blah blah,
gilliam 2004-09-23".
paul> It it well known that a 'KFAIL' durring a test may have nothing
paul> to do with what is being tested?
Yes. The very first KFAIL was in gdb.cp/annota2.exp, for PR gdb/544,
which is not an annotation bug but is actually a control-c handling race
in the event loop.
Michael
next prev parent reply other threads:[~2004-09-23 17:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-21 21:43 Paul Gilliam
2004-09-22 14:01 ` Andrew Cagney
2004-09-22 16:56 ` Paul Gilliam
2004-09-22 19:54 ` Andrew Cagney
2004-09-23 2:13 ` Paul Gilliam
2004-09-23 17:08 ` Michael Chastain [this message]
2004-09-23 17:25 ` Michael Chastain
2004-09-24 22:38 ` Test "set backtrace ..."; " Andrew Cagney
2004-09-23 17:25 ` Michael Chastain
2005-04-07 17:27 Paul Gilliam
2005-04-14 19:36 ` Daniel Jacobowitz
2005-04-15 23:38 ` Paul Gilliam
2005-04-27 15:49 ` Daniel Jacobowitz
2005-04-27 20:02 ` Paul Gilliam
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=4152FD9A.nail1OT1PXJKP@mindspring.com \
--to=mec.gnu@mindspring.com \
--cc=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=pgilliam@us.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