Re: [patch, testsuite] Clean up gdb.trace results

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2018-10-11 01:19, Sandra Loosemore wrote:
> If the architecture isn't one of those supported by trace-common.h,
> then actions.c (or any other program that includes trace-common.h)
> won't compile.  E.g. here is a recent gdb.sum extract for nios2-elf
> (using gdb 8.2 branch):
> 
> Running
> /scratch/sandra/nios2-elf-fall-preview/src/gdb-master-8.2/gdb/testsuite/gdb.trace/actions.exp
> ...
> gdb compile failed, In file included from
> /scratch/sandra/nios2-elf-fall-preview/src/gdb-master-8.2/gdb/testsuite/gdb.trace/actions.c:24:
> /scratch/sandra/nios2-elf-fall-preview/src/gdb-master-8.2/gdb/testsuite/gdb.trace/trace-common.h:61:2:
> error: #error "unsupported architecture for trace tests"
>  #error "unsupported architecture for trace tests"
>   ^~~~~
> /scratch/sandra/nios2-elf-fall-preview/src/gdb-master-8.2/gdb/testsuite/gdb.trace/actions.c:
> In function 'main':
> /scratch/sandra/nios2-elf-fall-preview/src/gdb-master-8.2/gdb/testsuite/gdb.trace/actions.c:146:26:
> error: 'fast_tracepoint_loc' undeclared (first use in this function)
>    FAST_TRACEPOINT_LABEL (fast_tracepoint_loc);
>                           ^~~~~~~~~~~~~~~~~~~
> /scratch/sandra/nios2-elf-fall-preview/src/gdb-master-8.2/gdb/testsuite/gdb.trace/actions.c:146:26:
> note: each undeclared identifier is reported only once for each
> function it appears in
> UNTESTED: gdb.trace/actions.exp: failed to compile
> 
> My patch does not change what targets the tests work on, it only makes
> it fail gracefully with UNSUPPORTED instead of spewing a bunch of
> compilation errors into the gdb.sum file and reporting UNTESTED.

Ah I see.  So to properly reproduce it (by faking it) on x86, I need to 
both make x86_supports_tracepoints return 0 and remove the x86-specific 
code in trace-common.h.  If I do that, I see that indeed, the output is 
not pretty (lots of compilation failures + untested).

> Well, the particular use case I've been looking at are nios2-linux-gnu
> and nios2-elf, and seeing my gdb.sum files full of random compilation
> errors and TCL ERRORs where I think it should just be reporting
> UNSUPPORTED.  Most of the compilation errors are coming from
> trace-common.h, and as I said, I'm under the impression that making
> this work involves adding target hooks to gdb and/or gdbserver and not
> just adding some stub for the arch to trace-common.h to prevent it
> from hitting the preprocessor #error and undefined symbol errors.  I'm
> really not even clear on the difference between "tracepoints" and
> "fast tracepoints" is, or which things which testcases are trying to
> test.
> 
> 
> IMO the problem here is that these tests were written with the
> assumption that the all support is present -- not just the tracepoint
> support, but things like shared libraries and signals that typically
> aren't supported on bare-metal targets, so they're just failing in
> really ugly ways when the necessary support isn't there.

That's true, and I'd say many tests are gdbserver-specific, since they 
load the in-process agent library.  If somebody has a different gdb stub 
implementation that supports tracepoints, that would be a good candidate 
to clean up the testsuite further, making sure we only run 
gdbserver-specific tests when testing against the actual gdbserver.

I have compared runs with/without your patch on x86 with the unix 
(default) and native-gdbserver boards, the results did not change. I 
then compared before/after runs using these boards but also mocking that 
tracepoints are not supported on x86, and the output is now much better. 
  So the patch LGTM, thanks!

Simon