From: Eli Zaretskii <eliz@gnu.org>
To: Keith Seitz <keiths@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA 4/4 doc] Explicit locations
Date: Fri, 21 Jun 2013 09:53:00 -0000 [thread overview]
Message-ID: <83a9mjooql.fsf@gnu.org> (raw)
In-Reply-To: <51C2349B.7080303@redhat.com>
> Date: Wed, 19 Jun 2013 15:45:47 -0700
> From: Keith Seitz <keiths@redhat.com>
> CC: gdb-patches@sourceware.org
>
> >> +@table @code
> >> +@item -source
> >> +The value specifies the source file name. This option
> >> +requires the use of either @code{-function} or @code{-line}.
> >
> > I think this should explain how to specify a file name unambiguously
> > (after all, this is what explicit locations are all about, right?).
> > For example, what if only a basename is specified? how to specify the
> > file name when several different files in the source tree have the
> > same basename?
>
> I've made an attempt at this. It probably needs a little more work,
> though, and the eyes of an outsider.
It looks fine to me.
> +#define LOCATION_HELP_STRING \
> +"Linespecs are a colon-separated list of location parameters, such as\n\
"Linespecs are colon-separated lists", in plural.
> +Address locations begin with \"*\" and specify an exact address in the.\n\
^
That period should be removed.
> +program. Example: To specify the fourth byte past the start function\n\
> +\"main\",use \"*main + 4\".\n\
^
Space before the comma here.
> -LOCATION may be a line number, function name, or \"*\" and an address.\n\
> -If a line number is specified, break at start of code for that line.\n\
> -If a function is specified, break at start of code for that function.\n\
> -If an address is specified, break at that exact address.\n\
> +LOCATION may be a linespec, address, or explicit location.\n\
> +\n" LOCATION_HELP_STRING "\n\
> With no LOCATION, uses current execution address of the selected\n\
> stack frame. This is useful for breaking on return to a stack frame.\n\
> \n\
I would move the "With no LOCATION ..." part before
LOCATION_HELP_STRING, since the latter is long. You can add
"as described below" to the preceding sentence, to make the reference
more explicit.
> +Clear breakpoint at specified location.\n\
> +Argument may be a linespec, explicit, or address location.\n\
> +\n" LOCATION_HELP_STRING "\n\
> With no argument, clears all breakpoints in the line that the selected
> frame\n\
> is executing in.\n\
> \n\
Likewise here (and elsewhere).
> +Locations may be specified using three different formats,
> +linespec locations, explicit locations, or address locations.
I would put a colon after "Different formats", not a comma.
> +sources. In these cases, explicit locations point to the source
> +line you meant more accurately and unequivocally. Also, using
^^^^^^^^^^^^^
I would use "unambiguously" here.
> +For example, the linespec ``foo:bar'' may refer to a function ``bar''
> +defined in the file named ``foo'' or the label ``bar'' in a function
> +named ``foo''. @value{GDBN} must search either the file system or
The markup here is incorrect. Drop the quotes, and use @file for file
names, @code for functions and labels, and @samp for everything else,
like @samp{foo:bar}.
> +@table @code
> +@item -source
> +The value specifies the source file name. To differentiate between
I would use a more explicit
@item -source @var{filename}
(and similarly for other options), like you did in the MI sections.
Otherwise, the only place where you hint on the format is the sentence
about "option-value pairs", and without an example this is not enough.
Btw, adding an example would be great.
> +to uniquely identify the desired file, e.g., ``foo/bar/baz.c''. Otherwise
^^^^^^^^^^^^^^^^^
Drop the quotes and use @file markup for file names.
> @smallexample
> -break-insert [ -t ] [ -h ] [ -f ] [ -d ] [ -a ]
> [ -c @var{condition} ] [ -i @var{ignore-count} ]
> - [ -p @var{thread-id} ] [ @var{location} ]
> + [ -p @var{thread-id} ] @var{location}
Is LOCATION no longer an optional parameter for -break-insert?
OK with those changes.
Thanks!
next prev parent reply other threads:[~2013-06-21 8:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-21 23:59 Keith Seitz
2013-03-22 1:00 ` Keith Seitz
2013-03-22 9:46 ` Eli Zaretskii
2013-06-20 0:11 ` Keith Seitz
2013-06-21 9:53 ` Eli Zaretskii [this message]
2013-06-21 23:32 ` Keith Seitz
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=83a9mjooql.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=keiths@redhat.com \
/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