This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] Fixes testsuit/gdb.base/annota1.exp
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