From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23761 invoked by alias); 2 Mar 2020 19:25:03 -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 23749 invoked by uid 89); 2 Mar 2020 19:25:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Google-DKIM-Signature:4bFg, HX-Received:6000 X-HELO: mail-wr1-f53.google.com Received: from mail-wr1-f53.google.com (HELO mail-wr1-f53.google.com) (209.85.221.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 02 Mar 2020 19:25:01 +0000 Received: by mail-wr1-f53.google.com with SMTP id j7so1174889wrp.13 for ; Mon, 02 Mar 2020 11:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=D9Y56gBQbFNdyG0kqYJiQKj5Ls9VkcdlRIubDi78O8Y=; b=R3lUhfE+zPwqkfuhwcoQpuli6FfErZQ8etIT0HJXvuGiECY3qs6J0XBPVV8x+zzwtq BWj9F6v0O8FwvsMb5HiZION7h0ZuuLvCJ0yx1wIl/Op05sit4pYzhvA7V5tDvBENvk2u LpMLkVwbfKMoI6TyWpt5zGsmZELnmdsOA1CsKHj86uwgo0e550z4Vj0CgrQrnEJDZ61Z Fngqpyjm8i1P+T/w7pTKOwnA69WoeNLOpUDHAlUaKCx/4zU6fhX7p0tYCEeK5FjWzNBg U8j3udJOyWZLJHq36SZY3TCs7g8h3gS4GxmFqyuGhI02ik34j106fFEeTppBN3Ou50vX x+YQ== Return-Path: Received: from localhost ([212.69.42.53]) by smtp.gmail.com with ESMTPSA id d203sm2451wmd.37.2020.03.02.11.24.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 02 Mar 2020 11:24:51 -0800 (PST) Date: Mon, 02 Mar 2020 19:25:00 -0000 From: Andrew Burgess To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCHv3 2/2] gdb/remote: Restore support for 'S' stop reply packet Message-ID: <20200302192450.GU3317@embecosm.com> References: <20200302151915.GQ3317@embecosm.com> <9af55184-812e-ecb6-a3ba-bb89106b82fb@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9af55184-812e-ecb6-a3ba-bb89106b82fb@redhat.com> X-Fortune: If life gives you lemons, make lemonade. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2020-03/txt/msg00042.txt * Pedro Alves [2020-03-02 19:07:33 +0000]: > On 3/2/20 3:19 PM, Andrew Burgess wrote: > > * Pedro Alves [2020-03-02 12:25:12 +0000]: > > >> "inferior" -> "target". > >> > >> The "inferior" -> "target" distinction I'm making in these > >> small remarks above matters, because say the remote server > >> is debugging two single-threaded inferiors. We still want to > >> (and do) warn. > > > > I hadn't really considered this case, however, this raises a > > follow on question: > > > > Before entering the target wait code we call > > switch_to_inferior_no_thread, partly, as I understand it because > > having inferior_ptid pointing at a thread leads to invalid code > > that relies on this thread being _the_ event thread, when really we > > need to extract the inferior and thread-id from the stop event. > > The main reason we switch the inferior is that the target stack is a > property of the inferior now. Each inferior has its own target stack > (see inferior::m_target_stack). Note, target stack, not target. > A single target may be used by different inferiors. E.g., > when remote debugging, if you're debugging two inferiors under control > of the same gdbserver, each inferior will have a pointer to the > same remote target instance in its target stack. > > To call any target method, we must be sure to make the relevant > inferior current, because target methods consult the inferior's > target stack to know which target to call. When target methods > defer to the target beneath, they'll again consult the target stack > stored in the current inferior (the "this->beneath ()->foo()" calls > in target-delegates.c). > > So to call the target_wait method to poll events out of some target, > you need to switch to some representative inferior that uses the > process_stratum target you want to poll. > > However, a reason we need to switch to all inferiors in turn and not > just a subset sufficient to cover all instantiated process_stratum > targets, is the strata above process_stratum, like record_stratum. > Those targets aren't shared between inferiors, and they generate > target events as well. > > I suspect it may be possible to come up with a cleaner design here, > but I haven't been able to come up with one that's as simple as the > current one, given all the constraints of the rest of current > gdb's design. I didn't try very hard though. > > Since we're switching the inferior around, the question > of -- which thread in the inferior should we pick? -- immediately > arises. And the best answer is "none". Switching to no-thread also > has the property that it "catches" target backends relying on > inferior_ptid to infer things about the next stopping event, > when they should not. (Another point that helps with seeing how that's > wrong is to consider that inferior_ptid includes no field > that would indicate which target instance the ptid came from. > So e.g., if you're debugging against two remote stubs, it could well > be the case that when you get to target_wait, inferior_ptid points at > a thread of the other target, even though it seemingly looks > like a valid thread in the current target.) > > > > > So, why do we allow the current_inferior to remain valid while we > > perform the wait? Instead, why don't we clear both current_inferior > > and inferior_ptid, and then enter the wait code? > > It's impossible to clear current_inferior with the current design. > There must always be a current inferior. Thanks for the explanation. Andrew