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]

Re: Update dg-extract-results.* from gcc


Hi Tom,

>>>>>> "Rainer" == Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
>
> Rainer> Therefore I propose to update both files from the gcc repo.  The changes
> Rainer> to the .sh version are trivial, just counting the number of DejaGnu
> Rainer> ERROR lines, too.
>
> Thank you for doing this.  This is ok.
>
> Rainer> * One could keep the files in toplevel contrib as in gcc, instead of
> Rainer>   stashing them away in gdb/testsuite.
>
> I don't have an opinion on this one, either way is ok by me.

On second thought, there are some arguments for moving them to toplevel
contrib:

* This way, they can easily be used should someone decide to parallelize
  one or more of the binutils, gas, or ld testsuites.

* They are less easily overlooked for updates from the gcc repo when
  they reside in the same place in both.

* The test_summary script needs to live in contrib since the toplevel
  Makefile's mail-report.log target expects it there.

So I'll go that route.

> Rainer> * One could also copy over gcc's contrib/test_summary, used by the
> Rainer>   toplevel make mail-report.log to provide a nice summary of test
> Rainer>   results.  However, this is currently hampered by the fact that for
> Rainer>   parallel make check the gdb.sum and gdb.log files are left in
> Rainer>   outputs/*/*/gdb.{sum,log} after dg-extract-results.sh has run instead
> Rainer>   of moving them to *.sep like gcc's gcc/Makefile.in does, so
> Rainer>   mail-report.log lists every failure twice.
>
> I don't understand the "*.sep" comment - would you mind spelling it out?

The test_summary scripts works by searching for *.sum and *.log files in
the whole tree (given that those live at different levels in the build
tree and cannot easily be found with a glob pattern).

Currently, once dg-extract-results.sh has summarized the individual
gdb.sum and gdb.log files in outputs, we have both the individual
per-subdir files in place and the summarized one in gdb/testsuite.  When
test_summary runs, it find all of of those and lists every non-PASS
result twice in its output, which isn't particularly helpful.

To avoid this, the gcc testsuite moves the subdir .sum/.log files for
parallelized testsuites to .sum.sep/.log.sep before passing them to
dg-extract-results.sh.  This way, we get one summary per testsuite
(e.g. gcc or g++, or gdb in the case at hand), and test_summary won't
pick them up twice.

> Anyway, if this script is useful to you, it's fine with me if you want
> to find a way to make it work.  I think the outputs/** stuff can be
> moved around or messed with pretty freely, though of course it is best
> not to outright lose things.

Absolutely: as I said, the individual files are just moved aside not to
interfere with the likes of test_summary, but still left in place since
dg-extract-results.* isn't always perfect in merging them.

I'll go ahead and prepare a patch then.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]