public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Pedro Alves <pedro@palves.net>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Improve break-range's documentation
Date: Tue, 31 May 2022 15:09:34 +0300	[thread overview]
Message-ID: <83leuhj43l.fsf@gnu.org> (raw)
In-Reply-To: <006eed32-3f65-61c4-686b-451cbdc40fb9@palves.net> (message from Pedro Alves on Tue, 31 May 2022 13:03:30 +0100)

> Date: Tue, 31 May 2022 13:03:30 +0100
> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> 
> >> +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.

  reply	other threads:[~2022-05-31 12:09 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-26 19:42 [PATCH v4] gdb/manual: Introduce location specs Pedro Alves
2022-05-27 14:16 ` Eli Zaretskii
2022-05-27 15:04   ` Pedro Alves
2022-05-27 15:52     ` Eli Zaretskii
2022-05-27 17:11       ` Pedro Alves
2022-05-27 17:31         ` Eli Zaretskii
2022-05-27 17:51           ` Pedro Alves
2022-05-27 18:23             ` Eli Zaretskii
2022-05-27 18:42               ` Pedro Alves
2022-05-27 18:50                 ` Pedro Alves
2022-05-27 19:00                   ` Eli Zaretskii
2022-05-27 19:30                     ` Pedro Alves
2022-05-28  7:43                       ` Eli Zaretskii
2022-05-30 14:38                         ` Pedro Alves
2022-05-27 18:55                 ` Eli Zaretskii
2022-05-27 19:05                   ` Pedro Alves
2022-05-27 19:14                     ` Eli Zaretskii
2022-05-27 19:17                       ` Pedro Alves
2022-05-27 19:34                         ` Eli Zaretskii
2022-05-27 19:38                           ` Pedro Alves
2022-05-28  7:39 ` Eli Zaretskii
2022-05-30 14:44   ` [pushed v5] " Pedro Alves
2022-05-30 16:15     ` Eli Zaretskii
2022-05-31 11:05       ` [PATCH] Improve clear command's documentation Pedro Alves
2022-05-31 12:36         ` Eli Zaretskii
2022-05-31 13:04           ` Pedro Alves
2022-05-31 13:42             ` Eli Zaretskii
2022-05-31 14:47               ` Pedro Alves
2022-05-31 16:06                 ` Eli Zaretskii
2022-05-31 11:13       ` [PATCH] Explicitly mention yet-unloaded shared libraries in location spec examples Pedro Alves
2022-05-31 11:47         ` Eli Zaretskii
2022-05-31 11:17       ` [pushed v5] gdb/manual: Introduce location specs Pedro Alves
2022-05-31 11:31       ` [PATCH] Improve break-range's documentation Pedro Alves
2022-05-31 11:55         ` Eli Zaretskii
2022-05-31 12:03           ` Pedro Alves
2022-05-31 12:09             ` Eli Zaretskii [this message]
2022-06-01 17:17     ` RTe: Location Specs (Was: [pushed v5] gdb/manual: Introduce location specs) Eli Zaretskii
2022-06-02 11:10       ` Pedro Alves
2022-06-02 11:49         ` Eli Zaretskii
2022-06-02 12:40           ` Pedro Alves
2022-06-02 12:56             ` Eli Zaretskii
2022-06-02 13:44               ` Pedro Alves
2022-06-02 16:37                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83leuhj43l.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@palves.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).