aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/print-ts.py
AgeCommit message (Collapse)AuthorFilesLines
2020-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files.
2019-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
This commit applies all changes made after running the gdb/copyright.py script. Note that one file was flagged by the script, due to an invalid copyright header (gdb/unittests/basic_string_view/element_access/char/empty.cc). As the file was copied from GCC's libstdc++-v3 testsuite, this commit leaves this file untouched for the time being; a patch to fix the header was sent to gcc-patches first. gdb/ChangeLog: Update copyright year range in all GDB files.
2018-11-25Implement timestamp'ed output on "make check"Sergio Durigan Junior1-0/+48
It is unfortunately not uncommon to have tests hanging on some of the BuildBot workers. For example, the ppc64be/ppc64le+gdbserver builders are especially in a bad state when it comes to testing GDB/gdbserver, and we can have builds that take an absurd amount of time to finish (almost 1 week for one single build, for example). It may be hard to diagnose these failures, because sometimes we don't have access to the faulty systems, and other times we're just too busy to wait and check which test is actually hanging. During one of our conversations about the topic, someone proposed that it would be a good idea to have a timestamp put together with stdout output, so that we can come back later and examine which tests are taking too long to complete. Here's my proposal to do this. The very first thing I tried to do was to use "ts(1)" to achieve this feature, and it obviously worked, but the problem is that I'm afraid "ts(1)" may not be widely available on every system we support. Therefore, I decided to implement a *very* simple version of "ts(1)", in Python 3, which basically does the same thing: iterate over the stdin lines, and prepend a timestamp onto them. As for testsuite/Makefile.in, the user can now specify two new variables to enable timestamp'ed output: TS (which enables the output), and TS_FORMAT (optional, used to specify another timestamp format according to "strftime"). Here's an example of how the output looks like: ... [Nov 22 17:07:19] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/call-strs.exp ... [Nov 22 17:07:19] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/step-over-no-symbols.exp ... [Nov 22 17:07:20] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/all-architectures-6.exp ... [Nov 22 17:07:20] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/hashline3.exp ... [Nov 22 17:07:20] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/max-value-size.exp ... [Nov 22 17:07:20] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/quit-live.exp ... [Nov 22 17:07:46] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/paginate-bg-execution.exp ... [Nov 22 17:07:56] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/gcore-buffer-overflow.exp ... [Nov 22 17:07:56] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/gcore-relro.exp ... [Nov 22 17:07:56] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/watchpoint-delete.exp ... [Nov 22 17:07:56] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/breakpoint-in-ro-region.exp ... [Nov 22 17:07:56] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/vla-sideeffect.exp ... [Nov 22 17:07:57] [1234] Running binutils-gdb/gdb/testsuite/gdb.base/unload.exp ... ... (What, gdb.base/quit-live.exp is taking 26 seconds to complete?!) Output to stderr is not timestamp'ed, but I don't think that will be a problem for us. If it is, we can revisit the solution and extend it. gdb/testsuite/ChangeLog: 2018-11-25 Sergio Durigan Junior <sergiodj@redhat.com> * Makefile.in (TIMESTAMP): New variable. (check-single): Add $(TIMESTAMP) to the end of $(DO_RUNTEST) command. (check-single-racy): Likewise. (check/%.exp): Likewise. (check-racy/%.exp): Likewise. (workers/%.worker): Likewise. (build-perf): Likewise. (check-perf): Likewise. * README: Describe new "TS" and "TS_FORMAT" variables. * print-ts.py: New file.