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.
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.