From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127399 invoked by alias); 13 Apr 2017 09:58:40 -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 127385 invoked by uid 89); 13 Apr 2017 09:58:40 -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=holding X-HELO: mail-wr0-f169.google.com Received: from mail-wr0-f169.google.com (HELO mail-wr0-f169.google.com) (209.85.128.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Apr 2017 09:58:38 +0000 Received: by mail-wr0-f169.google.com with SMTP id z109so32433350wrb.1 for ; Thu, 13 Apr 2017 02:58:40 -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=0/QsFvbUnQEBwXpHb7qluDhgB88PUg7GJEpWIhC1grs=; b=Bp2y8UGlqpTuNH8O9RNPlDI69i3bceArwu5jWS+W2jubYgTcVkupQQQOc/eCL4bafJ USzGAvJnix4JU3Y3q+JLb7IsXvGAv89Ok6mQBShvXob67/MWXQyzyL6KwM9cAj769FQZ GXCj133Ibb5Tcq+JiTQ1lRocZ9vMjzJO+ZFz7myXzoUVrbAL2GvlTK4FUguuXinZxtMG cft2DscXnXTVkKL3awDnrbEnDWwfvajNZb9oCfjBl3UIQyFQHVvVeHO1AeDQBut++UjW a7tW+J4BtNQA+TnaGUTTl/BIzCcHFQw4oiZm+ftchcRbdm8nBvpaOR02OOTttvIQJmCO 5SQw== X-Gm-Message-State: AN3rC/5ePSMY3fDJvrN9wr0bMPxDTfWtaRYNihao6Jy8M/Vf1dWRpzDP 6j3cCH35YNHxDsZX X-Received: by 10.223.139.146 with SMTP id o18mr1955053wra.175.1492077518398; Thu, 13 Apr 2017 02:58:38 -0700 (PDT) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id g63sm9926767wme.11.2017.04.13.02.58.37 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 13 Apr 2017 02:58:37 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 2/8] Fix follow-fork latent bug References: <1491954673-29172-1-git-send-email-palves@redhat.com> <1491954673-29172-3-git-send-email-palves@redhat.com> Date: Thu, 13 Apr 2017 09:58:00 -0000 In-Reply-To: <1491954673-29172-3-git-send-email-palves@redhat.com> (Pedro Alves's message of "Wed, 12 Apr 2017 00:51:07 +0100") Message-ID: <86a87kaasz.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/msg00409.txt.bz2 Pedro Alves writes: > - old_chain =3D save_inferior_ptid (); > - save_current_program_space (); > + old_chain =3D save_current_space_and_thread (); >=20=20 > inferior_ptid =3D child_ptid; > add_thread (inferior_ptid); > + set_current_inferior (child_inf); > child_inf->symfile_flags =3D SYMFILE_NO_READ; Can we set up child thread_info inferior and pspace first, and then, call switch_to_thread_no_regs to switch them in one go? >=20=20 > /* If this is a vfork child, then the address-space is > @@ -631,6 +631,7 @@ holding the child stopped. Try \"set detach-on-fork\= " or \ >=20=20 > inferior_ptid =3D child_ptid; > add_thread (inferior_ptid); > + set_current_inferior (child_inf); --=20 Yao (=E9=BD=90=E5=B0=A7)