From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2Oa0J+4gd2dNQQEAWB0awg (envelope-from ) for ; Thu, 02 Jan 2025 18:27:42 -0500 Received: by simark.ca (Postfix, from userid 112) id A04E01E097; Thu, 2 Jan 2025 18:27:42 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) 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=unavailable autolearn_force=no version=4.0.0 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 5A9BF1E091 for ; Thu, 2 Jan 2025 18:27:42 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 087F43858414 for ; Thu, 2 Jan 2025 23:27:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 087F43858414 Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by sourceware.org (Postfix) with ESMTP id BBAEF3858D21 for ; Thu, 2 Jan 2025 23:27:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BBAEF3858D21 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 BBAEF3858D21 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=78.133.224.34 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1735860432; cv=none; b=LIucPxIeUy8yXjfFswsZB8vYidw0Kuygl6Egvk3Wdnw52B+uI28AKrJD2CM+SvERJO9sq6SQCb9i2OCChaQmX0XqQClUhFTGGV9E/nODDWiJ2z26uPhTAMW0PBR0AhoC4nORuhFYNL2RoKeuYa+dY0hdjr7ZUMurbpPyT47Uqzs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1735860432; c=relaxed/simple; bh=x+m8L54eUnzDqjwMIpRgYRU/02Xecp2sPrILhLaCfo4=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=EBZYDQGglcwZPS6q2nJaDui+XYmrYD1jgxLTIcED40rxongOvhxRpc8rseEtGVCwKAThnvk7lyfmboxucd0Lfrs9pS17ZhSeOv8P6oYE2c9CuykI/H43PNgkpKWTd8HAQ+UFrmFbKRiUWycpedv3NtqnVwd0cbtTx1Sdd549tME= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BBAEF3858D21 Received: by angie.orcam.me.uk (Postfix, from userid 500) id C1A7292009C; Fri, 3 Jan 2025 00:27:11 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id BD92A92009B; Thu, 2 Jan 2025 23:27:11 +0000 (GMT) Date: Thu, 2 Jan 2025 23:27:11 +0000 (GMT) From: "Maciej W. Rozycki" To: Eli Zaretskii cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH] Clarify documentation of signal numbers In-Reply-To: <867c7ta6j8.fsf@gnu.org> Message-ID: References: <20241220201940.3235367-1-tromey@adacore.com> <867c7ta6j8.fsf@gnu.org> 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 Sat, 21 Dec 2024, Eli Zaretskii wrote: > It's clear enough, IMO. But I wonder whether we should simply have a > table of POSIX signal numbers 1-15 and the corresponding names, as GDB > converts them. Then the examples you show (which describe just some > of those conversions) will be unnecessary, and we only need to say > that signals 1-15 are interpreted as POSIX says and as shown in the > table. A table is IMO better because if someone uses GDB on a > non-POSIX platform, they don't necessarily have easy access to header > files on a POSIX platform to find out which signal is, say, signal 11. > So the only way for them to know is to type > > (gdb) handle 11 stop > > and see what GDB shows in response, which is not always > possible/convenient. FWIW I think it would make sense to show signal number information along with output from `info signal'. I wasn't aware even you could use numbers rather than names here. Maciej