This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
>>>>> "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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |