From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34626 invoked by alias); 25 Jan 2019 18:23:08 -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 34618 invoked by uid 89); 25 Jan 2019 18:23:08 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 25 Jan 2019 18:23:07 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 06A2CC04AC54; Fri, 25 Jan 2019 18:23:06 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 05D0D16C1A; Fri, 25 Jan 2019 18:23:04 +0000 (UTC) Subject: Re: [PATCH] gdbserver: When attaching, add process before lwps To: Alan Hayward , "gdb-patches@sourceware.org" References: <20190125104834.2595-1-alan.hayward@arm.com> Cc: nd From: Pedro Alves Message-ID: <0e75277b-fa80-129d-e82b-3f854bb33124@redhat.com> Date: Fri, 25 Jan 2019 18:23:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190125104834.2595-1-alan.hayward@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-01/txt/msg00551.txt.bz2 On 01/25/2019 10:48 AM, Alan Hayward wrote: > The recent BP/WP changes for AArch64 swapping the order in add_lwp() > so that the process was added before the lwp. This was due to the lwp > creation requiring the process data. > > This also needs changing in linux_attach(). > > Fixes gdb.server/ext-attach.exp on Aarch64. > > (This regression was hidden due to the racy nature of the gdb.server > tests - now they are no longer racy it'll be easier to spot. Also > checked X86). > > gdb/gdbserver/ChangeLog: > > 2019-01-25 Alan Hayward > > * linux-low.c (linux_attach): Add process before lwp. > --- > gdb/gdbserver/linux-low.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c > index 17cce24d76..1ab2cfb1eb 100644 > --- a/gdb/gdbserver/linux-low.c > +++ b/gdb/gdbserver/linux-low.c > @@ -1188,6 +1188,8 @@ linux_attach (unsigned long pid) > ptid_t ptid = ptid_t (pid, pid, 0); > int err; > > + proc = linux_add_process (pid, 1); > + > /* Attach to PID. We will check for other threads > soon. */ > err = linux_attach_lwp (ptid); > @@ -1198,8 +1200,6 @@ linux_attach (unsigned long pid) > error ("Cannot attach to process %ld: %s", pid, reason.c_str ()); > } > > - proc = linux_add_process (pid, 1); > - This fails to consider the error conditions. That error call visible above throws an exception. - If GDBserver is already attached to the process, this will create another process_info object for the already-attached process, and leave it behind. For this case, it would seem better to check whether we're already attached to a given PID in common code, around server.c:attach_inferior. - If GDBserver isn't already attached, but the attach fails, this will likewise leave a stale process_info object behind. Thanks, Pedro Alves