From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86404 invoked by alias); 28 Feb 2018 16:27:26 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 86394 invoked by uid 89); 28 Feb 2018 16:27:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Feb 2018 16:27:24 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 20090402314E; Wed, 28 Feb 2018 16:27:23 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id A43F59C051; Wed, 28 Feb 2018 16:27:22 +0000 (UTC) From: Sergio Durigan Junior To: Yao Qi Cc: "Maciej W. Rozycki" , Markus Metzger , Subject: Re: [PATCH v2 5/7] btrace, gdbserver: remove the to_supports_btrace target method References: <1516976072-19282-1-git-send-email-markus.t.metzger@intel.com> <1516976072-19282-6-git-send-email-markus.t.metzger@intel.com> <86woyxgw7l.fsf@gmail.com> Date: Wed, 28 Feb 2018 16:27:00 -0000 In-Reply-To: <86woyxgw7l.fsf@gmail.com> (Yao Qi's message of "Wed, 28 Feb 2018 12:00:46 +0000") Message-ID: <87o9k9m651.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00465.txt.bz2 On Wednesday, February 28 2018, Yao Qi wrote: > "Maciej W. Rozycki" 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. Ah, that explains the failures I am seeing. > 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. What I can do is manually cancel all the build until Markus's commit. I've done that before for other builders, so it is possible. I'll keep an eye and do that when the commit is pushed. Thanks for keeping me in the loop, Yao. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/