Re: [Commit] testsuite/gdb.pascal

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Pierre" == Pierre Muller <muller@ics.u-strasbg.fr> writes:

Pierre> PS: Tom, could you help me out with the 
Pierre> patch tester scripts?

Sorry about that -- I saw your ping on irc, but then forgot to send
you a follow-up email.

I use the two attached scripts to regression test patches.

The tester requires that you use archer git.  That is because git
provides a way to select the proper baseline revision for a patch.  It
might be possible to make it work with CVS... I don't plan to do that
but if you want to figure something out, I'll assist if I can.  If you
need the actual tester script to do this I can email that to you (or
you can see it in ~tromey on gcc11).

The first script makes a patch in a format that the tester
understands.  This format is just an ordinary git diff with a short
header describing the baseline revision, where to send email, etc.
You can run this anywhere in your git tree.  You can supply some
options to change how the tester configures and builds gdb; you can
also change this by editing the patch header before submission.  The
default is to configure with --enable-targets=all, and build with -j6.

The second script uploads a patch to the patch tester.  It is
basically a fancy "scp".

My typical pattern is to check out archer's "master" branch (which is
frequently synced with gdb cvs) and write a patch.  I test it locally,
write new tests, etc.  Then I "mkdiff > /tmp/whatever.diff" and
"submit-patch /tmp/whatever.diff".  Then when the patch is approved, I
apply it to gdb cvs for committing.

Once you've uploaded a patch, you'll get an email when the tester
starts work on it.  Then you'll get another message when the test is
done.  Occasionally I have noticed that this second email gets wedged;
I don't know why.  If that happens, let me know, or you can log in and
dig through ~tromey/auto-test-gdb to find the results.

I've noticed that the results comparison script fails to notice if you
introduce new FAILs.  It doesn't consider those as failures.  If
anybody has a bulletproof test result comparison script, I'm
interested.

I periodically go through the old test results and delete them by
hand.  I probably ought to automate this.

The gdb test suite itself is a bit noisy.  There are a few tests that
randomly fail.  So, the tester may report some errors which you can
ignore -- if you resubmit the patch, they will go away.  For example,
this is a common false negative:

    gdb.sum gdb.threads/schedlock.exp: other threads ran - unlocked

Let me know if you have any trouble.

Tom

Attachment: mkdiff
Description: mkdiff

Attachment: submit-patch
Description: submit-patch