Re: [PATCH v2 5/7] btrace, gdbserver: remove the to_supports_btrace target method

[Yao Qi <qiyaoltc at gmail dot com>]

"Maciej W. Rozycki" <macro@mips.com> writes:

>  Hmm, v3 of this change (apparently never posted), that is specifically 
> commit de6242d30757 ("btrace, gdbserver: remove the to_supports_btrace 
> target method"), has broken remote `mips-linux' target debugging 
> completely, that is an attempt to make a remote connection fails in the 
> initial handshake, e.g.:
>
> Process .../gdb/testsuite/outputs/gdb.base/advance/advance created; pid = 25519
> Listening on port 2346
> target remote 1.2.3.4:2346
> Remote debugging using 1.2.3.4:2346
> Reading symbols from .../lib/ld.so.1...done.
> 0x77fc8de0 in __start () from .../lib/ld.so.1
> Protocol error: qXfer:btrace-conf (read-btrace-conf) conflicting enabled responses.
> (gdb) continue
> The program is not being run.
> (gdb) FAIL: gdb.base/advance.exp: can't run to main

For the record, since non-x86 gdbserver is broken, it takes much longer
to run gdb tests on non-x86 gdbserver buildbot builders,
On Ubuntu-AArch64-native-gdbserver-m64, the time is changed from 17 mins
to 5 hrs 50 mins; 
https://gdb-build.sergiodj.net/builders/Ubuntu-AArch64-native-gdbserver-m64/builds/4141
On CentOS-ppc64be-native-gdbserver-m64, the time is changed from 48 mins
to 6 hrs 34 mins;
https://gdb-build.sergiodj.net/builders/CentOS-ppc64be-native-gdbserver-m64/builds/155

CentOS-ppc64le-native-gdbserver-m64, Fedora-ppc64le-native-gdbserver-m64 and
Debian-s390x-native-gdbserver-m64 are affected as well.

By the time Markus's fix is pushed in, these builders can run tests for
only 4 commits every day, and there are already 184 commits pushed after
commit de6242d30757.  It takes at least 46 days to build and test every
commit.  If we take "try" jobs submitted in the last several days into
account, it takes more time to clear the queue.

Sergio, in short, non-x86 gdbserver is broken, it takes several hours to
run gdb tests with gdbserver builders.  As a result, many builds are
pending there, and it still also takes much time to clean them up.
After Markus commit his fix, can we do something to let non-x86
gdbserver builders to skip these pending builds, and "jump" to Markus's fix?
Or can we temporarily disable non-x86 builders, restart them after the
fix is committed, and make sure builders pick the most recent commit
rather than resuming from the pending builds.

-- 
Yao (齐尧)