----- Original Message ----- > From: "Jonathan Wakely" <jwak...@redhat.com> > To: "Marc Poulhies" <mpoulh...@kalrayinc.com> > Cc: "libstdc++" <libstd...@gcc.gnu.org>, "gcc-patches" > <gcc-patches@gcc.gnu.org>, "Luc Michel" <lmic...@kalray.eu> > Sent: Wednesday, July 21, 2021 5:53:52 PM > Subject: Re: [NEWS] libstdc++: Fix testsuite for skipping gdb tests on > remote/non-native target
> Thanks for the patch. I agree we should skip the version checks, not > only the actual tests. But I wonder whether we want to do that in > xmethods.exp and prettyprinters.exp rather than in the gdb_batch_check > proc. Or maybe like this instead: > > I don't think it really makes much difference, I'm just unsure what is > "cleaner" and more consistent with DG conventions and/or the rest of > the gdb-test.exp file. Here are a bit more information on the issue we are having. While trying to understand why the testsuite is taking a long time to execute, we (Luc in Cc) discovered that the logs contain: Spawning: gdb -nw -nx -quiet -batch -ex "python print(gdb.lookup_global_symbol)" spawn -ignore SIGHUP kvx-mppa --unnamed-log --bootcluster=node0 --no-trap --no-gdb-attach --dcache-no-check -- gdb -nw -nx -quiet -batch -ex python print(gdb.lookup_global_symbol) UNSUPPORTED: prettyprinters.exp testcase /work1/mpoulhies/tools-csw/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp completed in 613 seconds kvx-mppa being a simulator and gdb the host (x86) binary. The strangest part being that running the command by hand will fail immediately, but when DG is running the tests, it waits until the timeout is reached: we don't understand this behavior, but we get several <defunct> processes probably waiting to be joined.. I don't have a strong opinion here as I'm really no DG expert. I find the filtering in gdb-test maybe more robust as it prevents any error like the above. Having the test in prettyprinters/xmethod allows for quicker exit (saves 15s here), but I don't see that as a strong argument. Thanks for the review, Marc
