Re: [PATCH] gdb/manual: Introduce locspecs

[Pedro Alves <pedro@palves.net>]

On 2022-05-25 22:24, Philippe Waroquiers wrote:
> On Wed, 2022-05-25 at 21:05 +0100, Pedro Alves wrote:
>> On 2022-05-25 20:56, Eli Zaretskii wrote:
>>>> From: Pedro Alves <pedro@palves.net>
>>>> Date: Wed, 25 May 2022 20:31:26 +0100
>>>>
>>>> To clarify this, I propose we use the term "Location Specification",
>>>> with shorthand "locspec", when we're talking about the user input, the
>>>> argument or arguments that is/are passed to commands to instruct GDB
>>>> how to find locations of interest.  This is distinct from the actual
>>>> locations in the program, which are what GDB finds based on the
>>>> user-specified locspec.  Then use "locspec" thoughout instead of
>>>> "location" when we're talking about the user input.
>>>
>>> Sorry, but I don't think this is a good idea.  It is IMO okay to
>>> introduce "location specification" into our terminology; it is even
>>> okay to use "location spec" as its shorthand.  But "locspec" is too
>>> much: it's not a word, so it doesn't explain itself enough, and thus
>>> cannot be used very far from where it is defined, because the reader
>>> will likely not understand what it means.
>>
>> Yet, we have "linespec" and people understand it just fine, it's described
>> once in a single spot in the manual.  "locspec" just sounds novel now, but it won't be
>> novel anymore once we start using it.  It sounds like you are against any term that
>> is new just because it is new.  That just blocks progress forever.  It is not reasonable.
>> New shorthand names for for things that are referred very frequently should be fine
>> to invent.  Our users aren't dummies and they learn things.

> IIUC, Eli would like to have location reserved for a breakpoint giving multiple resulting
> locations.

No, he was saying he would prefer "location" to be reserved for location specifications,
and to find a different name for breakpoint locations.  I would find that really odd -- a breakpoint
is passed a location specification, and then we plant a breakpoint instruction on
each of the program locations that matches the specification.  Each breakpoint location
really represents a program location, with address, function, file and line all being important.
So it's natural to call each of those a different location.  I don't see why would we even
bother to consider renaming breakpoint locations to something else.

> 
> Why not then use   breakpoint specification/bkptspec for the first concept
> and location for the second ?

"breakpoint specification" wouldn't work because we have many commands that take
a location spec as argument that have nothing to do with breakpoints.  For example:

(top-gdb) info line main
Line 365 of "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operators/char/2.cc" starts at address 0x86dee9 <selftests::string_view::operators_2::main()>
   and ends at 0x86def1 <selftests::string_view::operators_2::main()+8>.
Line 73 of "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/substr/char/1.cc" starts at address 0x86c097 <selftests::string_view::operations_substr_1::main()>
   and ends at 0x86c09f <selftests::string_view::operations_substr_1::main()+8>.
Line 62 of "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/rfind/char/3.cc" starts at address 0x86bd5a <selftests::string_view::operations_rfind_3::main()>
   and ends at 0x86bd62 <selftests::string_view::operations_rfind_3::main()+8>.
Line 47 of "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/rfind/char/2.cc" starts at address 0x86b9a6 <selftests::string_view::operations_rfind_2::main()>
   and ends at 0x86b9ae <selftests::string_view::operations_rfind_2::main()+8>.
...


(top-gdb) list -function main
file: "/home/pedro/gdb/binutils-gdb/src/gdb/gdb.c", line number: 25, symbol: "main(int, char**)"
20      #include "main.h"
21      #include "interps.h"
22
23      int
24      main (int argc, char **argv)
25      {
26        struct captured_main_args args;
27
28        memset (&args, 0, sizeof args);
29        args.argc = argc;
file: "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/capacity/1.cc", line number: 166, symbol: "selftests::string_view::capacity_1::main()"
161       VERIFY( sz03 >= sz04 );
162     }
163
164     static int
165     main()
166     {
167       test01();
168
169       return 0;
170     }
...

(top-gdb) edit main
Specified line is ambiguous:
file: "/home/pedro/gdb/binutils-gdb/src/gdb/gdb.c", line number: 25, symbol: "main(int, char**)"
file: "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/capacity/1.cc", line number: 166, symbol: "selftests::string_view::capacity_1::main()"
file: "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/cons/char/1.cc", line number: 61, symbol: "selftests::string_view::cons_1::main()"
file: "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/cons/char/2.cc", line number: 40, symbol: "selftests::string_view::cons_2::main()"
file: "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/cons/char/3.cc", line number: 33, symbol: "selftests::string_view::cons_3::main()"
...

Etc.

Please take a look at the v2 patch I sent, and its description, where you'll
find plenty of examples more.  If you look at the patch's diff itself, you'll
find I added text to several commands describing what they do when the spec
matches multiple locations.