Re: [PATCH v2 1/2] Always show locations for breakpoints & show canonical location spec

[Pedro Alves <pedro@palves.net>]

On 2022-05-26 20:55, Eli Zaretskii wrote:
>> Date: Thu, 26 May 2022 20:29:50 +0100
>> Cc: gdb-patches@sourceware.org
>> From: Pedro Alves <pedro@palves.net>
>>
>> I documented all this in the Location Specifications section.  I'll send v4 in a bit.
>>
>> I did not go for "source locations", however.  I swear I am not trying to be
>> difficult...  The issue is that as I tried to describe things, "source location" read
>> awkwardly, and kind of a lie-ish.  Because, you can have usable resolved locations without
>> sources, even if they are incomplete.  It depends on command if they are usable.  Instead, I
>> noticed something.
>>
>> Here:
>>
>>   * List::                        Printing source lines
>>  -* Specify Location::            How to specify code locations
>>  +* Location Specifications::     How to specify code locations
>>                                                  ^^^^^^^^^^^^^^
>>
>> And note what the intro paragraph of that node currently says:
>>
>>   "Several GDB commands accept arguments that specify a location or locations of your program’s code."
>>
>> Clearly the arguments specify something, and that something is ... "locations of your program’s code."
>>
>> So I went with "code locations" instead.
> 
> I could agree with this, but note that you are contradicting yourself:
> "code" can and is sometimes interpreted as "machine code", and thus
> "code location" can be interpreted as "address", something you didn't
> want.  

I didn't want "address" specifically, because it is either incorrect or
misleading.  E.g., "info macro" doesn't work with addresses, but you had
suggested to say "address" for this one at some point.  I was also worried
with "addresses that match locspec", as it is sort of ambiguous with address
locations.  Breakpoints are set with the complete location coordinate, just
the address is not enough to identify the location properly, given inlining.
Explaining what "code location" means in the location specification chapter
and talking about locspecs resolved to addresses, works, but just plain
address doesn't.

> By contrast, "source location" is unequivocally a source-level
> concept, and reflects the fact that it refers to a certain line of
> source code in a certain file.  Moreover, it follows the example of
> that C++ page you yourself used as an argument.  Why now you deviate
> from all that is a mystery for me.

I pointed at the C++ page as an argument for the word "location", which
you so strongly wanted to replace by something else, like "place" or "address"
or some other unknown term.  I had never understood that you would be fine with
a qualifier on top of location.  I wish I had known earlier.  

It's great we managed to meet in the middle somewhere.

> 
> But if you don't care about all these inconsistencies, "code location"
> is fine with me, as it qualifies the overly-general "location" enough
> to solve the potential ambiguity, which was what bothered me.

Great, let's go with it.

> 
>> Anyhow, you'll see in v4 in a bit.
>>
>> I hope you will be happy with this one.
> 
> Thanks.

Looking forward for a review.