Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Don Breazeal <donb@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 3/3] Target remote mode fork and exec docs
Date: Thu, 12 Nov 2015 16:48:00 -0000	[thread overview]
Message-ID: <83mvuji2p9.fsf@gnu.org> (raw)
In-Reply-To: <1447290000-31393-2-git-send-email-donb@codesourcery.com>

> From: Don Breazeal <donb@codesourcery.com>
> Date: Wed, 11 Nov 2015 17:00:00 -0800
> 
> >> +@item
> >> +Finally, connect to your target.  For TCP connections, you must start up
> >> +@code{gdbserver} prior to using the @kbd{target remote} or
> >> +@kbd{target extended-remote} command.  Otherwise you may get an error
> >> +whose text depends on the host system, but which usually looks something
> >> +like @samp{Connection refused}.  Don't use the @code{load} command in
> >> +@value{GDBN} when using @code{gdbserver}, since the program is already on
> >> +the target.
> > 
> > There's some inconsistency in your usage of @code and @kbd markup for
> > commands.  In general, the correct markup is @kbd when the context is
> > about commands typed by the user, and @code otherwise.  (The GDB
> > manual almost never uses @kbd, for historical reasons, btw.)  You have
> > changed some of the @code to @kbd regardless of context, or so it
> > seems.  But in the above passage, you use @code as well, so I'm unsure
> > what is your rule for selecting one or the other.
> 
> I misunderstood the convention here.  Thanks for clarifying.  I think I
> have more-or-less restored things.  Basically, as I understand it, the rule
> is: use @kbd where the sentence is saying "type @kbd{foo}" or "use
> @kbd{foo}", but use @code if it is just referring to it, like "in the
> case of the @code{foo} command".

Yes, that's it.

> +@table @asis
> +
> +@cindex remote debugging, detach and program exit
> +@item Result of detach or program exit
> +
> +@strong{target remote mode:} When the debugged program exits or you
> +detach from it, @value{GDBN} disconnects from the target.  When using
> +@code{gdbserver}, @code{gdbserver} will exit.
> +
> +@strong{target extended-remote mode:} When the debugged program exits or

This is OK, but the fact that "target extended-remote mode:" part that
begins a sentence doesn't start with a capital letter looks wrong.
How about starting with @strong{With target extended-remote mode:}
instead?

> +@item The @code{run} command
> +@strong{target remote mode:} The @code{run} command is not supported.

Please be consistent regarding whether or not you leave an empty line
after the @item line.  (My suggestion is not to leave such a line in a
@table.)

>  If you're using a serial line, you may want to give @value{GDBN} the
>  @samp{--baud} option, or use the @code{set serial baud} command
>  (@pxref{Remote Configuration, set serial baud}) before the
> -@code{target} command.
> +@kbd{target} command.

Here you show 2 commands in the same sentence, one with @code, the
other with @kbd.  I think both should use @code.

> +In @code{target extended-remote} mode, you can also attach using the
> +@value{GDBN} attach command
> +(@pxref{Types of Remote Connections: Attaching}).

I don't understand this @pxref -- there's no such node or anchor in
the text.  Does this work for you?  (Also, using a colon in
cross-reference or node names is a bad idea, as that confuses Info
readers.)

The patch is approved, assuming the above minor issues are fixed.

Thanks.


  reply	other threads:[~2015-11-12 16:48 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-06 23:56 [PATCH 0/3] Target remote mode fork and exec support Don Breazeal
2015-11-06 23:57 ` [PATCH 3/3] Target remote mode fork and exec docs Don Breazeal
2015-11-07  8:18   ` Eli Zaretskii
2015-11-12  1:00     ` Don Breazeal
2015-11-12 16:48       ` Eli Zaretskii [this message]
2015-11-13  1:13         ` Don Breazeal
2015-11-13  8:16           ` Eli Zaretskii
2015-11-12  1:00     ` Don Breazeal
2015-11-06 23:57 ` [PATCH 2/3] Target remote mode fork and exec tests Don Breazeal
2015-11-06 23:57 ` [PATCH 1/3] Target remote mode fork and exec events Don Breazeal
2015-11-20 13:04   ` Pedro Alves
2015-11-20 16:50     ` Don Breazeal
2015-12-07 22:14     ` [PATCH v2 0/3] Target remote mode fork and exec support Don Breazeal
2015-12-07 22:14       ` [PATCH v2 1/3] Target remote mode fork and exec tests Don Breazeal
2015-12-08 12:58         ` Pedro Alves
2015-12-14 19:29           ` [pushed] " Don Breazeal
2015-12-07 22:14       ` [PATCH v2 2/3] Target remote mode fork and exec events Don Breazeal
2015-12-08 12:55         ` Pedro Alves
2015-12-14 19:29           ` Don Breazeal
2015-12-15 10:52             ` Pedro Alves
2015-12-07 22:15       ` [PATCH v2 3/3] Target remote mode fork and exec docs Don Breazeal
2015-12-08 13:07         ` Pedro Alves
2015-12-14 19:30           ` [pushed] " Don Breazeal
2015-12-08 13:11       ` [PATCH v2 0/3] Target remote mode fork and exec support Pedro Alves

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=83mvuji2p9.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=donb@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    /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