Re: [PATCH v4] gdb/manual: Introduce location specs

[Eli Zaretskii <eliz@gnu.org>]

> From: Pedro Alves <pedro@palves.net>
> Date: Thu, 26 May 2022 20:42:50 +0100
> 
>  gdb/doc/gdb.texinfo | 419 +++++++++++++++++++++++++-------------------
>  gdb/doc/guile.texi  |   2 +-
>  gdb/doc/python.texi |   5 +-
>  3 files changed, 246 insertions(+), 180 deletions(-)

Thanks.  The changes in descriptions of the commands that accept
location specs seem more-or-less okay, although I didn't yet read all
of them  in detail (so please don't push just yet).  The "Location
Specifications" section, OTOH, needs more work.  I didn't yet make up
my mind regarding what exactly should it look like, and one reason why
I'm not there yet is that your text doesn't seem to describe the "code
location" in full:

  > +A concrete code location in your program is uniquely identifiable by a
  > +set of logical attributes.  Typically, a line number, the source file
  > +the line belongs to, the fully-qualified and prototyped function it is
  > +defined in, and an instruction address.  Because each inferior has its
  > +own address space, also an inferior number.

The "typically" part and the overall style seem to say that this is
not the exhaustive list of all the attributes of a code location, just
a general idea.  Can you please present a full exhaustive list of the
attributes of a code location?

And another question: does the process of resolving a location spec to
obtain the corresponding code locations involve only filling in of the
attributes that were omitted from the spec, or does it also produce
attributes that can _never_ be part of the location spec?  IOW, can
the user type a location spec which will yield a code location that is
100% identical to the input spec?

IMO, the best way to describe "location specifications", "code
locations", and how the former leads to the latter depends on the
answers to those two questions.

Thanks.