From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id xopXOgWuKGkxkDkAWB0awg (envelope-from ) for ; Thu, 27 Nov 2025 15:01:09 -0500 Received: by simark.ca (Postfix, from userid 112) id E03571E048; Thu, 27 Nov 2025 15:01:09 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED 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 0BB4E1E048 for ; Thu, 27 Nov 2025 15:01:05 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 966E6385841F for ; Thu, 27 Nov 2025 20:00:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 966E6385841F Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by sourceware.org (Postfix) with ESMTP id 973643858D1E for ; Thu, 27 Nov 2025 20:00:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 973643858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 973643858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:4190:8020::34 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1764273623; cv=none; b=L1C+eyHWOK8PA1Il/IQu2f9umDnJ2YdHEl8hrDgkwYO3O6o7F/N8EYXplkZEU9nnRnZja9+/YuNYpLIbcDERfZW0dIB3KBbJy7RwHDu1ZnjRqP94SdGNoHq56XBJCDzfxxlkhgj3HIONbcGLjUs5TPtiIksCSi6rvzIS5n2yHwU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1764273623; c=relaxed/simple; bh=Jl64Z8hT3PDr+GrsBsN3ogTzJJk5W3HY/b3juWTV9Qg=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=OsAqfpwucKUeXoL+VhdEj6iNMcykppsnWdbycrtZrhxEwCXQxGUu0BUIXfMaS96EKNFcDoz/phbVGFhwRriTlnIv/qV2DdFtZs7N314hOxu+q6Md7slOXPwU0LslIWEj2fl+YpNKmCoIC0l4vUyom4nuX/nETR+A4fvh9vzqHws= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 973643858D1E Received: by angie.orcam.me.uk (Postfix, from userid 500) id 9233D92009C; Thu, 27 Nov 2025 21:00:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 8E90C92009B; Thu, 27 Nov 2025 20:00:22 +0000 (GMT) Date: Thu, 27 Nov 2025 20:00:22 +0000 (GMT) From: "Maciej W. Rozycki" To: Guinevere Larsen cc: gdb-patches@sourceware.org Subject: Re: [PATCH 1/2] gdb: introduce command "info architecture" In-Reply-To: <67dc2271-4c15-42d1-bd1a-d77e2cd1e6df@redhat.com> Message-ID: References: <20251106194514.1857177-1-guinevere@redhat.com> <20251106194514.1857177-2-guinevere@redhat.com> <67dc2271-4c15-42d1-bd1a-d77e2cd1e6df@redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 On Thu, 27 Nov 2025, Guinevere Larsen wrote: > > We could reword output from `set architecture' so as not to suggest the > > use without an argument is invalid. > > > > In any case the listing facility must not be an `info' subcommand, as > > these are meant for showing the state of the debuggee, > > I disagree, in my opinion, this new command would function basically just like > "info unwinder", giving information on how GDB is able to interact with the > inferior. Is it the semantics documented in the manual since forever (search for it and when it appeared there) that you disagree with? I don't know what `info unwinder' is about, but maybe someone got it wrong too and it should be a `show' subcommand instead. > > while the set of > > architectures supported is a property of the given instance of GDB itself, > > and therefore suitable for the `set'/`show' commands. So if a new command > > it would have to be `show architecture list' or suchlike. > > My understanding is that set/show commands are mostly used for when the user > could change something, and the point of this command is showing the user the > compilation options that were used, there's no changes that a user could do. Same as with: (gdb) show version -- it can't be changed by the user and there's no corresponding `set' command. Maciej