From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4KsVO+qX5WBKXQAAWB0awg (envelope-from ) for ; Wed, 07 Jul 2021 08:02:50 -0400 Received: by simark.ca (Postfix, from userid 112) id EE3591F1F2; Wed, 7 Jul 2021 08:02:50 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A05A71E01F for ; Wed, 7 Jul 2021 08:02:50 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 486D63951C0E for ; Wed, 7 Jul 2021 12:02:50 +0000 (GMT) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by sourceware.org (Postfix) with ESMTPS id 1B4BB395188E for ; Wed, 7 Jul 2021 12:01:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1B4BB395188E 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-wr1-f54.google.com with SMTP id i94so2768202wri.4 for ; Wed, 07 Jul 2021 05:01:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0X0nV0Lm88BuFOLiljKQvKBBfxbS8L10bdpHgga8t78=; b=o0kML7hOjv2e2JXL9bXZSErcV8MdfaWtfiOGr7jkIn2kn2J+Ou4DiPl635cC52hTu3 XJ79K0RcmFXy3p4smmsjSKVFp5/FN3fW+h4CvH9jQC7TH2jI5/fD2v2AHJlFdG3DQQD4 kSJEX7bw5dtEgKIvTuZC0orvMGvX15Os1w64B1yScaCohUhMRYqhPCz4ZiheAMOVOvsZ MJwTxyQp5bPIUeOF+TtLHV5nTQgRzVpgDU4wVaZbU5HDRbqIPtbkuEEkos9KJGetyryy T7CHx4Dx+dVoMa6Ppt6HtUEtB63VjxwjFVRcIh3ODmEj66EkDTEk02YXF+4VzOhKw/T3 GpYw== X-Gm-Message-State: AOAM530zbf42fi0iEIO5gTYker+ylQyShA69aS7vF5DDzR+O5mSNsEqU aU1T3Mc1cN3qD4cqMJwMN0HcER1VBQBbNQ== X-Google-Smtp-Source: ABdhPJxJp372dLL6rn2L1Fi4EOMK2o9EjH8qzsBsubrd2QcEu7nAEVPeU6cvxEXEP1t3merJySgXzA== X-Received: by 2002:adf:a351:: with SMTP id d17mr10161473wrb.364.1625659299295; Wed, 07 Jul 2021 05:01:39 -0700 (PDT) Received: from ?IPv6:2001:8a0:f932:6a00:46bc:d03b:7b3a:2227? ([2001:8a0:f932:6a00:46bc:d03b:7b3a:2227]) by smtp.gmail.com with ESMTPSA id v11sm1588596wrs.4.2021.07.07.05.01.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jul 2021 05:01:38 -0700 (PDT) Subject: Re: [PATCH 07/11] gdb: maintain per-process-target list of resumed threads with pending wait status From: Pedro Alves To: Simon Marchi , gdb-patches@sourceware.org References: <20210622165704.2404007-1-simon.marchi@polymtl.ca> <20210622165704.2404007-8-simon.marchi@polymtl.ca> <52c8488e-fef2-a1fe-d150-50d510bedbe1@palves.net> <252f2a84-c7b4-d07a-fecc-c57685a89ee1@polymtl.ca> Message-ID: <25ce9332-1145-6cfa-1520-540fe17debd6@palves.net> Date: Wed, 7 Jul 2021 13:01:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <252f2a84-c7b4-d07a-fecc-c57685a89ee1@polymtl.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2021-07-06 10:25 p.m., Simon Marchi wrote: >>> + we don't leave any threads of this inferior in the target's "resumed with >>> + pending wait status" list. */ >>> + if (t->stratum () == process_stratum) >>> + { >>> + process_stratum_target *proc_target = as_process_stratum_target (t); >>> + >>> + for (thread_info *thread : this->non_exited_threads ()) >>> + proc_target->maybe_remove_resumed_with_pending_wait_status (thread); >> >> Note the target_pid_to_str call inside maybe_remove_resumed_with_pending_wait_status >> adds back a dependency on current_inferior. > > Arggg, we don't want that. Since that is in a process_stratum_target > method, I'll change the message to call the pid_to_str method of the > current object instead: > > infrun_debug_printf ("removing from resumed threads with event list: %s", > this->pid_to_str (thread->ptid).c_str ()); > > Does that sound good? It does not. That would mean a target higher on the stack wouldn't have a chance at printing the thread. >> >>> + m_resumed_with_pending_wait_status.push_back (*thread); >>> + } >>> +} >>> + >>> +/* See process-stratum-target.h. */ >>> + >> >>> + >>> +private: >>> + /* List of threads managed by this target which simultaneously are resumed >>> + and have a pending wait status. */ >> >> I'd suggest expanding this comment a little to mention this >> is done for optimization reasons, to avoid walking >> thread lists, something like that. Or maybe say that in >> the thread_info node. Or both places. > > Done: > > /* List of threads managed by this target which simultaneously are resumed > and have a pending wait status. > > This is done for optimization reasons, it would be possible to walk the > inferior thread lists to find these threads. But since this is something > we need to do quite frequently in the hot path, maintaining this list > avoids walking the thread lists repeatedly. */ > > I would prefer to avoid repeating the same thing at two places, because > it's a recipe for the two places getting out of sync. Since the node > comment in thread_info now points to here (says the list head is in > process_stratum_target), people looking for more information about this > list should have no problem finding the comment here. > Looks good. >> >>> + thread_info_resumed_with_pending_wait_status_list >>> + m_resumed_with_pending_wait_status; >>> }; >>> >>> /* Downcast TARGET to process_stratum_target. */ >>> diff --git a/gdb/thread.c b/gdb/thread.c >>> index 289d33c74c3b..26974e1b8cbc 100644 >>> --- a/gdb/thread.c >>> +++ b/gdb/thread.c >>> @@ -188,6 +188,10 @@ set_thread_exited (thread_info *tp, bool silent) >>> >>> if (tp->state != THREAD_EXITED) >>> { >>> + process_stratum_target *proc_target = tp->inf->process_target (); >>> + if (proc_target != nullptr) >> >> I think this check needs a comment. > > Done: > > /* Some targets unpush themselves from the inferior's target stack before > clearing the inferior's thread list (which marks all threads as exited, > and therefore leads to this function). In this case, the inferior's > process target will be nullptr when we arrive here. > > See also the comment in inferior::unpush_target. */ > > And I also added a cross-reference to here from the comment in > inferior::unpush_target. Great. > >>> + /* If we transition from not resumed to resumed, we might need to add >>> + the thread to the resumed threads with pending statuses list. */ >>> + if (resumed) >>> + proc_target->maybe_add_resumed_with_pending_wait_status (this); >> >> Longest function name award goes to... ;-) > > Indeed! If you have a name that is shorter but just as clear, I'm open > for suggestion. But I prefer names that are non-ambiguous and use the > right terminology over names that are short just for convenience's sake. Sure, as a preference, though that shouldn't be a too-strict rule IMO, otherwise with very long function names we can end up with awkward looking code as soon as we need to indent a caller a couple levels. In this case, luckily that didn't happen, so I'm not really objecting. "add_resumed_pending_status" or "add_resumed_pending_ws" would work as well for me, for example.