From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id WPWwKZEFlmLEdgkAWB0awg (envelope-from ) for ; Tue, 31 May 2022 08:09:53 -0400 Received: by simark.ca (Postfix, from userid 112) id A6FFC1E221; Tue, 31 May 2022 08:09:53 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=B+3d3dii; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 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 4219D1E00D for ; Tue, 31 May 2022 08:09:53 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B7FE23836651 for ; Tue, 31 May 2022 12:09:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B7FE23836651 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1653998992; bh=g1HOY6qfLYdA+dsq+9/BVYSMJ8cNyGoJf/QG/B795kU=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=B+3d3diiDEO1aNCEvGZFjRcA+I2YNXf2aIaxeoiLy4fqAtmsQqc8iOn5Tf745FvnS wk9w6C/JKT1/JncY6HWDqPQWNtaiPTqIJpQIJ76Q3/bzdu0J7sZliY1e/XwyDCAww3 deXPoYEFnBkI19Z4Zpf2227w+sv3U+FTIzIrNM7k= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 719E53858D33 for ; Tue, 31 May 2022 12:09:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 719E53858D33 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35350) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nw0gm-0002eK-Oj; Tue, 31 May 2022 08:09:33 -0400 Received: from [87.69.77.57] (port=4598 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nw0gi-0008Nf-Ud; Tue, 31 May 2022 08:09:30 -0400 Date: Tue, 31 May 2022 15:09:34 +0300 Message-Id: <83leuhj43l.fsf@gnu.org> To: Pedro Alves In-Reply-To: <006eed32-3f65-61c4-686b-451cbdc40fb9@palves.net> (message from Pedro Alves on Tue, 31 May 2022 13:03:30 +0100) Subject: Re: [PATCH] Improve break-range's documentation References: <20220526194250.2310460-1-pedro@palves.net> <838rqmm7gb.fsf@gnu.org> <6914f754-4e33-5aa1-4ea6-dca9504e8bfe@palves.net> <837d63j8tx.fsf@gnu.org> <83r149j4qq.fsf@gnu.org> <006eed32-3f65-61c4-686b-451cbdc40fb9@palves.net> 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: , From: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > Date: Tue, 31 May 2022 13:03:30 +0100 > Cc: gdb-patches@sourceware.org > From: Pedro Alves > > >> +specs. @value{GDBN} resolves both @var{start-locspec} and > >> +@var{end-locspec}, and uses the addresses of the resolved code > >> +locations as start and end addresses of the range to break at. If > >> +either @var{start-locspec} or @var{end-locspec} resolve to multiple > >> +code locations in the program, then the command aborts with an error > >> +without creating a breakpoint. The breakpoint will stop execution of > >> +the inferior whenever it executes an instruction at any address > >> +between the start and end addresses, inclusive. > > > > This is fine, but please swap the last sentence with the one before > > it, since, as written, the penultimate sentence breaks the logic of > > the description of what the command does by describing an exceptional > > situation too early. > > The way it is written made sense to me, as we first say GDB resolves > the locspecs, and then the exceptional situation is exactly about the > resolving we just described. IME, it is usually better to describe what the command does normally, and only after that what it does in an exceptional case. Users are usually after the former. > Anyhow, I'll change it and merge. Thanks.