From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by sourceware.org (Postfix) with ESMTPS id 9AFF6385780C for ; Fri, 29 Apr 2022 15:39:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9AFF6385780C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f41.google.com with SMTP id p189so4836376wmp.3 for ; Fri, 29 Apr 2022 08:39:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=gX+A8tt6aUbwI5XFCz4dWong+mdB3crlyzoM5bBA9Pg=; b=rh7GxpD8IXA9iyN+E8lSk64dk+qm7qBLp6gLAV80yrwY20lNZ32VLKoFPftxFCm5NV lFRTwNXdg5QUFhr1+o95K8xiqVhh99kQ5itHkiLFI6yHSHLKdAxaWpARkmbxhlD7NXId VATMkn7OdPNnJ1wv7B+3ge53VDA+47XN80s8oQlvEJiyBaOdGTSWvWaLh/wjM6ILLAop rI3WBFd2uklVECYpQyDUGsJLAbDs35ic/x+X0XvL4Qx2boDDb1xVQt3Wa7OFk0QwABXI sUgjjFVH1Sq+n/yU7Q/7pz3cfEBUe24VCBWICmlJG3twgvvv7Q6P9Vpjx75SayG6Gpdr d3Ig== X-Gm-Message-State: AOAM532/3FZvtipcbGFwQE+UId/kTWSHrQbKnQ1IAeycNqS6FrGc0Z1E 8K52yKKyfzXQyIqtuXOsxwYF9NXdjeQ= X-Google-Smtp-Source: ABdhPJzK4thp0ijtPrRHFcnQNPE8iifppIXvxPNKAguaPCmb8W1ee1Uu9Eijz72v18dPuOzIrbezXQ== X-Received: by 2002:a1c:2b86:0:b0:392:ae97:2fec with SMTP id r128-20020a1c2b86000000b00392ae972fecmr3678574wmr.165.1651246764288; Fri, 29 Apr 2022 08:39:24 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id y9-20020a05600015c900b0020adb0e106asm3670139wry.93.2022.04.29.08.39.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 08:39:23 -0700 (PDT) Message-ID: <622785b8-ed10-e0d2-f24d-45990ec9ea9c@palves.net> Date: Fri, 29 Apr 2022 16:39:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH 2/2] gdb/remote: return early from remote_check_symbols if waiting for stop reply Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org References: <20220424032049.1021263-1-simon.marchi@polymtl.ca> <20220424032049.1021263-3-simon.marchi@polymtl.ca> <3bea5140-e1ef-940d-6a60-0f7864534507@palves.net> <2656736d-da78-ba44-3997-eaba0d07290e@polymtl.ca> From: Pedro Alves In-Reply-To: <2656736d-da78-ba44-3997-eaba0d07290e@polymtl.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.2 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2022 15:39:27 -0000 On 2022-04-29 15:53, Simon Marchi wrote: > On 2022-04-29 08:50, Pedro Alves wrote: > Since inferiors can share a program space, perhaps the call to > target_has_execution here is just wrong, since it only checks one (the > current) inferior. What if you have two inferiors sharing a program > space, one with execution and one without. If remote_new_objfile gets > called with the one without execution as the current inferior, we'll > conclude we have no execution and won't send qSymbol. But maybe we > should have sent it, for the benefit of the inferior that has execution. > > So maybe we need to change the question from "does the current inferior > have execution" to "does any inferior in the affected program space have > execution", since the current inferior is not always reliable. And > anyway, an objfile change is pspace-specific, not inferior-specific. I think so, yes. > > Something like that: > > diff --git a/gdb/remote.c b/gdb/remote.c > index ff98024cd78..9888aab88bd 100644 > --- a/gdb/remote.c > +++ b/gdb/remote.c > @@ -5116,14 +5116,6 @@ remote_target::remote_check_symbols () > char *tmp; > int end; > > - /* The remote side has no concept of inferiors that aren't running > - yet, it only knows about running processes. If we're connected > - but our current inferior is not running, we should not invite the > - remote target to request symbol lookups related to its > - (unrelated) current process. */ > - if (!target_has_execution ()) > - return; > - > if (packet_support (PACKET_qSymbol) == PACKET_DISABLE) > return; > > @@ -14595,6 +14587,22 @@ remote_new_objfile (struct objfile *objfile) > if (current_inferior ()->in_initial_library_scan) > return; > > + bool has_execution = false; > + program_space *pspace = current_program_space; > + for (inferior *inf : all_inferiors (remote)) > + { > + if (inf->pspace != pspace) > + continue; > + > + has_execution = remote->has_execution (inf); > + > + if (has_execution) > + break; > + } > + > + if (!has_execution) > + return; > + > remote->remote_check_symbols (); > } > remote_new_objfile has another reference to current_inferior(): /* Function to be called whenever a new objfile (shlib) is detected. */ static void remote_new_objfile (struct objfile *objfile) { ... if (current_inferior ()->in_initial_library_scan) return; remote->remote_check_symbols (); } so seems to me that it should be here that we'd loop over inferiors.