This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] GDB testsuite patch.
Good morning Manoj,
This design is okay but the implementation needs some more work.
Here's a whole bunch of comments. Please re-work your patch and
re-submit it.
Don't let the length of this email intimidate you. This is mostly
procedural stuff that everybody runs into when they start working on FSF
projects.
Michael
-- Anchor the tail of the pattern.
Your pattern says:
-re "Reading symbols from.*no debugging symbols found.* $"
This works as long as gdb output arrives in one big packet.
However, sometimes the gdb output gets broken up and arrives
in several packets. When that happens, the ".* $" at the end
of your pattern will succeed prematurely before all of the
packets arrive, leaving some unmatched characters in the stream.
So you have to write:
-re "Reading symbols from.*no debugging symbols found.*$gdb_prompt $"
That forces the pattern to keep scanning gdb output until it
gets to the final "(gdb) ".
-- ChangeLog entry. When you submit a patch, please submit a ChangeLog
entry to go with it. In general, the right ChangeLog file is the
ChangeLog file nearest to the file that you are patching. In this
case, it's gdb/testsuite/ChangeLog.
And you format the ChangeLog paragraph as a little block of
text in front of the "diff", rather than including
"diff ChangeLog" with the diff. That's the Gnu style;
it makes it easier to merge patches.
See the gdb-patches mailing list archive for examples.
-- Test with current gdb. I noticed your test was with gdb 6.1.
You should at least be testing with gdb 6.2; preferably with
the CVS version of gdb.
-- Run the whole test suite.
A change in lib/gdb.exp affects the execution of every test script.
It's great to show that gdb.gdb/complaints.exp improved. But you
also have to check that other tests didn't get broken.
The procedure is:
check out the CVS version of gdb
run the whole test suite
save the gdb.sum and gdb.log files
apply your patch
run the whole test suite again
diff the first gdb.sum against the new gdb.sum
if there are differences, check out what changed in gdb.log
Unfortunately, there are about six test scripts that are unstable
and give different results from run to run. So you have to use
your judgement with these, which generally means "ignore them":
gdb.cp/annota2.exp
gdb.cp/annota3.exp
gdb.threads/manythreads.exp
gdb.threads/print-threads.exp
gdb.threads/schedlock.exp
gdb.threads/watchthreads.exp
If you're not sure whether a change in gdb.sum results came
from your patch or from run-to-run instability, you can
check the gdb-testers@ archive and see if I've mentioned that
particular test in my results. Or you can ask me or ask one
of the lists. Or you can submit the patch anyways and say
"I saw a regression in gdb.foo/bar.exp but I'm not sure if
my patch caused it or not".
Getting back to the "whole test suite" ... there is at least
one test script, gdb.base/nodebug.exp, which explicitly tests
how gdb works when the target program has no debugging symbols.
Your patch might interfere with that. So you have to run the
whole test suite before-and-after, to find any interference
like that.
-- Last, patch submissions for gdb go to the gdb-patches@ mailing
list, not the gdb@ mailing list.