From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130804 invoked by alias); 13 Apr 2017 11:33:45 -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 130768 invoked by uid 89); 13 Apr 2017 11:33:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=super X-HELO: mail-wm0-f43.google.com Received: from mail-wm0-f43.google.com (HELO mail-wm0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Apr 2017 11:33:41 +0000 Received: by mail-wm0-f43.google.com with SMTP id t189so44770506wmt.1 for ; Thu, 13 Apr 2017 04:33:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=DoLJORUp8mG+U4cKk/YlyfyaQ+L6wesDtWTcChsuk2U=; b=LD8ej/CkhOeg+6mwJKYpTNrzHIH69gYlQFibbDgVu+/UhsLSQ5tjqKxzMsg0mLR5vX W7BSmaPP1TptXaQ6hr3volzbU7f0mT/ai2mA9A51z8n/jpHv2+u6nYiyb/rTRXUQ6GC/ swaPkIqMxKpK733j2Fnd6Euz1elvV1W+x0E/SU/sFqX31svQ5SXTPH1ni4E0ZGuV4xZY FZCCma4K+a+cKTtLvqhPncsTMJ8P0EfUGfwTvOBoC17//btpFhSIJmQ7e4Bb7ptMWddB n2X1xYgQ+/kJQtQbjENUgiD0bvNxi/1f6GT/44SkY5FebP+2RkdCHaeZxBqfxAKMZOFF 09Xg== X-Gm-Message-State: AN3rC/5PeZCLBQZwoaYwBZDM0c/009uXcaUsKkMeW7j50fq66nMEYDfh yNqqIE4NxBMCtHeV X-Received: by 10.28.156.13 with SMTP id f13mr11736778wme.44.1492083220961; Thu, 13 Apr 2017 04:33:40 -0700 (PDT) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id 3sm23050377wrv.33.2017.04.13.04.33.40 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 13 Apr 2017 04:33:40 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 8/8] Fix removing inferiors from within "thread apply" commands References: <1491954673-29172-1-git-send-email-palves@redhat.com> <1491954673-29172-9-git-send-email-palves@redhat.com> Date: Thu, 13 Apr 2017 11:33:00 -0000 In-Reply-To: <1491954673-29172-9-git-send-email-palves@redhat.com> (Pedro Alves's message of "Wed, 12 Apr 2017 00:51:13 +0100") Message-ID: <86o9w08ru5.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00416.txt.bz2 Pedro Alves writes: > @@ -313,9 +319,31 @@ public: > explicit inferior (int pid); > ~inferior (); >=20=20 > + /* Returns true if we can delete this inferior. We can't delete it > + if it is the current inferior, or if there's code out there that > + relies on it existing (m_refcount > 0). */ > + bool deletable () const > + { > + return m_refcount =3D=3D 0 && this !=3D current_inferior (); > + } > + > /* Pointer to next inferior in singly-linked list of inferiors. */ > struct inferior *next =3D NULL; >=20=20 > + /* Increase the refcount. */ > + void incref () > + { > + gdb_assert (m_refcount >=3D 0); > + m_refcount++; > + } > + > + /* Decrease the refcount. */ > + void decref () > + { > + m_refcount--; > + gdb_assert (m_refcount >=3D 0); > + } > + > /* Convenient handle (GDB inferior id). Unique across all > inferiors. */ > int num =3D 0; > @@ -431,6 +459,12 @@ public: >=20=20 > /* Per inferior data-pointers required by other GDB modules. */ > REGISTRY_FIELDS; > + > +private: > + /* If this is > 0, then it means there's code out there that relies > + on this inferior existing. Don't allow deleting it in that > + case. */ > + int m_refcount =3D 0; > }; Can we move them to a super class, so that both thread and inferior can extend it? >=20=20 > -/* Switch from one thread to another. */ > +/* Switch to no thread selected. */ >=20=20 > -void > -switch_to_thread (ptid_t ptid) > +static void > +switch_to_no_thread () > { > - /* Switch the program space as well, if we can infer it from the now > - current thread. Otherwise, it's up to the caller to select the > - space it wants. */ > - if (ptid !=3D null_ptid) > - { > - struct inferior *inf; > + if (inferior_ptid =3D=3D null_ptid) > + return; >=20=20 > - inf =3D find_inferior_ptid (ptid); > - gdb_assert (inf !=3D NULL); > - set_current_program_space (inf->pspace); > - set_current_inferior (inf); > - } > + inferior_ptid =3D null_ptid; > + reinit_frame_cache (); > + stop_pc =3D ~(CORE_ADDR) 0; > +} >=20=20 > - if (ptid =3D=3D inferior_ptid) > +/* Switch from one thread to another. */ > + > +static void > +switch_to_thread (thread_info *thr) > +{ > + gdb_assert (thr !=3D NULL); > + > + if (inferior_ptid =3D=3D thr->ptid) > return; >=20=20 > - inferior_ptid =3D ptid; > + /* Switch the current program space and current inferior as > + well. */ > + set_current_program_space (thr->inf->pspace); > + set_current_inferior (thr->inf); > + > + inferior_ptid =3D thr->ptid; Can these code be replaced by switch_to_thread_no_regs? --=20 Yao (=E9=BD=90=E5=B0=A7)