From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2gnNFRBQCmiZbwMAWB0awg (envelope-from ) for ; Thu, 24 Apr 2025 10:52:00 -0400 Received: by simark.ca (Postfix, from userid 112) id 477061E0C3; Thu, 24 Apr 2025 10:52:00 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.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 ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id AE27A1E0C0 for ; Thu, 24 Apr 2025 10:51:59 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 472103858C62 for ; Thu, 24 Apr 2025 14:51:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 472103858C62 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by sourceware.org (Postfix) with ESMTPS id 38BDE3858D21 for ; Thu, 24 Apr 2025 14:50:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 38BDE3858D21 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 38BDE3858D21 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.128.49 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1745506248; cv=none; b=TGVUA99wo4fImn1GWxvAcsWKIyGS7JrUrgkHSfF3EzBa2ZA4raGSE5sQC6aZVRlCeJuGCyk61OmKQGwz+CwDX7bioBir7VfENuZTMBe3N7FONatDTcZz47BY6tHLVoDKU0yBk8mX3e8lrgF/N29vQiobUIhxwAP86/VUWHhvTMk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1745506248; c=relaxed/simple; bh=9eJ+O9qxLfKD9+LODfOV9QfkKgBF69XodjEZ+rokL80=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=Bg8ptpyEhwiiXYZTAC0kSaM0F+KXUoG47dpBrzydps9uXs70BvEb79NaYPwNbR1i9R/hCLKDGRyJahSR00hcggYtDdqk/E0fKDKXveoh4qC8tjvh+h4Q7H+UdRx7fF32VaThgg9VzVCgYMg0NIs4w8Ouht2ztwyOu3G6W61CBAU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 38BDE3858D21 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-43cf680d351so14116105e9.0 for ; Thu, 24 Apr 2025 07:50:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745506247; x=1746111047; h=content-transfer-encoding:in-reply-to:content-language:from :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BNaapyDCr/SMenRbZo/kB1V74yz+dFa6URhDCPMXDTw=; b=UkMB1Iwd5rNrO2TCBBpQOke2yi3d7YOfCinMByviS5dXgo061z1251fK8FJ6JIeNsD xeBQlVxGscIzbNc1E58T5qafNAnalQkWNEnJE7XGp72/KNXiky7JTB38LGIoFszqsLlg sDlEV9x/KYujtIYRyPtrv9SYYdXIY0hfpJNhnkATKkP7NZ7LIDjhmLO4KzHm8lStcEFy j57edTFfC2voLcYtFdevDfWEKlUOlMvIG9Kkw80VF8cyx5OogInkvfdaqeWNRbwtrTZc H+SwPPtn4E0oufA6ZRft6vFBWc5Yl68mtByfQ/VC2/Y2C7vMOTj1jKLI854lIKlWfo/K Y9gA== X-Forwarded-Encrypted: i=1; AJvYcCVIkOcYpThTVH8lnQWo5t3jGblNLAL8Pd45UUmXKE6CvwKOkrPKvsSJkZ9bCaA8a6NlEk/pkKM3BbZflA==@sourceware.org X-Gm-Message-State: AOJu0YyMC+v2IimWe/scMc/KnWy3c6ENr4vjkfS6fRa/pVyH4WNegoXy aQY0ZwCz2fPAxN4JXP/cinuwWdE6x7wvYQ7h+i4uHnVQzeRUXwjv2p5rf5oZ X-Gm-Gg: ASbGnctbsv08Uow3tjAmPcGL0ta+z1Gjwd8xxGGFFj2FOUSSLjXFVsLiXYZUgmxYcqM CwCb34fGJ0SrS3Cex1LmpgQskpUNpBnx+ApkSQNjcqAkglZsIL4A6CgRd897rDRbcdWsL6N92KF eWGaantAZ6bUeoBDP3za04nYxSxeNv3mZoVg6UBqTxpS9+PTMIetCzfD/nWaTX7BroPxr0r2F3Y Tl3R/toHhSUUHAMrMK2SOgEbYR5d9n04IMz+GrTjd/cunwUwLB+gm49sNSJBtlnDYJGYbTsmVrD EomNkAovn8Ywwiwx6+3BgkNvWA0tpBPHxr9juMFFZt+noAp1Y/mhyR4Xl9UcQlGIgo+ujy+CDJm RoDtLqL5A X-Google-Smtp-Source: AGHT+IHl1+1JHLOERqOWm/j5IeWSZo4Oh8i72/lv5Yn6keQKamniWBhDGC80Zna92/kk9ka9vHoxAQ== X-Received: by 2002:a05:600c:c092:b0:43d:186d:a4bf with SMTP id 5b1f17b1804b1-4409c399b9amr22599165e9.0.1745506246924; Thu, 24 Apr 2025 07:50:46 -0700 (PDT) Received: from ?IPV6:2001:8a0:4fcf:3e00:704c:2a3a:5212:7960? ([2001:8a0:4fcf:3e00:704c:2a3a:5212:7960]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4409d2a3afbsm23714675e9.16.2025.04.24.07.50.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Apr 2025 07:50:46 -0700 (PDT) Message-ID: <53eb1690-487c-4bdb-ac33-a32e986d7509@palves.net> Date: Thu, 24 Apr 2025 15:50:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] gdb: add a '-stopped' option to "info threads" To: "Aktemur, Tankut Baris" , Eli Zaretskii , "gdb-patches@sourceware.org" References: <83ileasl6h.fsf@gnu.org> <83edoysiv7.fsf@gnu.org> From: Pedro Alves Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 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 Hi! On 2023-04-05 12:31, Aktemur, Tankut Baris via Gdb-patches wrote: > On Wednesday, April 5, 2023 12:51 PM, Eli Zaretskii wrote: >>> From: "Aktemur, Tankut Baris" >>> Date: Wed, 5 Apr 2023 10:19:26 +0000 >>> >>> I'm fine if we make the single thread id a special case. >> >> Maybe that's all we should do. >> >>> But then the question is, where do we draw the line? If the user >>> gave just a few thread ids, do we still ignore the flag? What is >>> the limit to the acceptable list length? Because of these >>> questions, consistently applying the flag made more sense to me. >> >> We don't have to be 100% consistent, we just need to be useful. > > Let's please wait a bit in case other maintainers want to chime in. > I don't have an objection to treating the single thread id case specially. I don't think we should give single ID any special treatment. It's as you say, what about "info thread 1 2 ", does that get an exception because it is two single IDs? Why would that be different from "info threads 1-2" ? What if I put the IDs in a convenience variable, and then do: (gdb) eval "info threads -stopped %s", $id Why should my script behave differently depending on what is saved in $id? Etc. BTW, the same rationale should apply to "thread apply". "info threads" and "thread apply" have basically the same logic and also share options. IMO, we should have a matching "thread apply -stopped" too. And with "thread apply", it is even clearer IMO that "thread apply $ID -stopped print foo" should not every try to run "print foo" on a not-stopped thread! From the fact that "info threads" and "thread apply" should walk the same threads given the same options, it follows that "info threads -stopped" should not walk any non-stopped thread. I'll look at later revisions of the series now. Thanks for doing this. We had talked about it a while ago but I hadn't realized you had sent it upstream. Thanks! Pedro Alves