From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105701 invoked by alias); 20 Dec 2017 15:24:39 -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 100654 invoked by uid 89); 20 Dec 2017 15:24:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-19.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=qi, Qi, H*c:alternative X-HELO: mail-qk0-f182.google.com Received: from mail-qk0-f182.google.com (HELO mail-qk0-f182.google.com) (209.85.220.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Dec 2017 15:24:24 +0000 Received: by mail-qk0-f182.google.com with SMTP id r184so19443604qke.8 for ; Wed, 20 Dec 2017 07:24:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tf8qhc95PqsKJm2Pg51YoPckAyyYaUnWVggS9X0SJf0=; b=rEztmKki9wB2lUjjdA4gRPUKigcJBWfTdxzwPuvgboGnvHV39+xRkdHOem7bMx8lgZ /Fh3EjXODmbYP+lKW6jALhX+7dlPLRIf5tjefaaV4KdYW3hcV/FJ4qJ1ynUuYmSvLysI XyqB208mIynDl+ctDx//rHt0LfS2I49ah466bejYvH4vliNCP3OkRizPA/zXVAR4uICy qGTTL/Gt9FI+gRpt37db1SwYSDYy4qtPSrfHuP7tr+uCDK9NBH7M4XAymgJ9RIOUBzvR OallzNlvo2gA08OaATmXSrpx591DOp/PcLgnhj8epTko3X14KJGG9xkOayRBBXxKlgUL Q0pw== X-Gm-Message-State: AKGB3mJ/pYVXRnC7PqfDXqiMCk5qoTqQtdy1aaCjNyhWufrcvrF9V5jr d6yLNFKoqK+pUZAj/vALow/x02LqofyQnq5Hg0cRSoHX X-Google-Smtp-Source: ACJfBov2YpDvBgya18qg327SCS5gvMmAZdmKvDNpsf5marPTSa+kDfW9P7y8dfYOvV+UhmTmtERQ9l09jLycVDVDBjg= X-Received: by 10.55.27.215 with SMTP id m84mr1186477qkh.319.1513783455662; Wed, 20 Dec 2017 07:24:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.103.216 with HTTP; Wed, 20 Dec 2017 07:23:45 -0800 (PST) In-Reply-To: <86o9mu8v32.fsf@gmail.com> References: <86o9mu8v32.fsf@gmail.com> From: Edjunior Machado Date: Wed, 20 Dec 2017 15:24:00 -0000 Message-ID: Subject: Re: ppc64* native-gdbserver testsuite hangs on gdb.threads/process-dies-while-handling-bp.exp To: Yao Qi Cc: GDB Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00452.txt.bz2 Hi Yao, thanks a lot for the patch! Testing the fix on Fedora26, confirmed that native-gdbserver no longer hangs on gdb.threads/process-dies-while-handling-bp.exp in both ppc64le and be. Unfortunately, I couldn't regtest running the complete testsuite due to another hang I'm still checking (likely caused by hw watch not working properly on such boxes). Thanks and regards, Edjunior On Tue, Dec 19, 2017 at 6:51 PM, Yao Qi wrote: > Yao Qi writes: > > > It is a known issue in GDB, described in PR 18749, rather than a > > regression, so git bisect can't tell you anything useful. Pedro fixed > > one GDBserver crash caused by 18749, but PR 18749 is still > > there. > > > > I can reproduce the timeout on gcc110, > > > > KFAIL: gdb.threads/process-dies-while-handling-bp.exp: non_stop=3Don: > > cond_bp_target=3D0: inferior 1 exited (timeout) (PRMS: gdb/18749) > > Remote debugging from host 127.0.0.1^M > > gdbserver: reading register 10: No such process^M > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Killing process(es): 15614^M > > monitor exit^M > > Ignoring packet error, continuing... > > > > I think some code path in GDBserver doesn't expect this error. > > Does this patch work for you? With this patch, > process-dies-while-handling-bp.exp never timeout on gcc110 with > native-gdbserver. > > -- > Yao (=E9=BD=90=E5=B0=A7) > From ef027cdb366e3000dee2c713abab4f30123d9ed1 Mon Sep 17 00:00:00 2001 > From: Yao Qi > Date: Tue, 19 Dec 2017 17:44:11 +0000 > Subject: [PATCH] Mark register unavailable when PTRACE_PEEKUSER fails > > As described in PR 18749, GDB/GDBserver may get an error on accessing > memory or register because the thread may disappear. However, some > path doesn't expect the error. This patch fixes this problem by > marking the register unavailable when PTRACE_PEEKUSER fails instead > of throwing error. > > gdb/gdbserver: > > 2017-12-19 Yao Qi > > PR gdb/18749 > * linux-low.c (fetch_register): Call supply_register instead of > error. > > diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c > index f6a52d5..0a52a91 100644 > --- a/gdb/gdbserver/linux-low.c > +++ b/gdb/gdbserver/linux-low.c > @@ -5555,7 +5555,11 @@ fetch_register (const struct usrregs_info *usrregs, > (PTRACE_TYPE_ARG3) (uintptr_t) regaddr, (PTRACE_TYPE_ARG4) > 0); > regaddr +=3D sizeof (PTRACE_XFER_TYPE); > if (errno !=3D 0) > - error ("reading register %d: %s", regno, strerror (errno)); > + { > + /* Mark register REGNO unavailable. */ > + supply_register (regcache, regno, NULL); > + return; > + } > } > > if (the_low_target.supply_ptrace_register) >