From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <eliz@gnu.org>
Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10])
 by sourceware.org (Postfix) with ESMTPS id 228EF385735C
 for <gdb-patches@sourceware.org>; Fri, 27 May 2022 18:55:34 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 228EF385735C
Received: from fencepost.gnu.org ([2001:470:142:3::e]:37158)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@gnu.org>)
 id 1nuf7V-0001hx-Ah; Fri, 27 May 2022 14:55:33 -0400
Received: from [87.69.77.57] (port=4009 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@gnu.org>)
 id 1nuf7R-0001qX-6U; Fri, 27 May 2022 14:55:31 -0400
Date: Fri, 27 May 2022 21:55:25 +0300
Message-Id: <83o7zin6ua.fsf@gnu.org>
From: Eli Zaretskii <eliz@gnu.org>
To: Pedro Alves <pedro@palves.net>
Cc: gdb-patches@sourceware.org
In-Reply-To: <113bd07c-3bfe-0780-50a9-4c41c84942e9@palves.net> (message from
 Pedro Alves on Fri, 27 May 2022 19:42:50 +0100)
Subject: Re: [PATCH v4] gdb/manual: Introduce location specs
References: <20220526194250.2310460-1-pedro@palves.net>
 <8335gvnjrw.fsf@gnu.org> <956e1fbd-5f03-c021-c390-82e1cf3493b5@palves.net>
 <83wne7m0ri.fsf@gnu.org> <2bc9b5c9-879a-2848-16f4-6cfd796563a8@palves.net>
 <83sfounaqw.fsf@gnu.org> <02a46873-35dc-0d9c-1890-292b807d9484@palves.net>
 <83pmjyn8as.fsf@gnu.org> <113bd07c-3bfe-0780-50a9-4c41c84942e9@palves.net>
X-Spam-Status: No, score=1.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH,
 DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF,
 RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: gdb-patches@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>,
 <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>,
 <mailto:gdb-patches-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Fri, 27 May 2022 18:55:35 -0000

> Date: Fri, 27 May 2022 19:42:50 +0100
> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> 
> > Yes, but note that the last revision of your patch says "resolves
> > into", not "matches".  Which I think is a change for the better; I'm
> > trying to have a more accurate idea of what that "resolution" entails.
> 
> Resolution is the act of find all the actual code location that match the user
> input.  The found locations are the resolved code locations.
> 
> Here for example:
> 
>  +@item list @var{locspec}
>  +Print lines centered around the line or lines that @var{locspec}
>  +resolves to.
> 
> The meaning is that the user passes some input spec to GDB, which
> may even not specify any line at all, like "line func", and GDB
> finds all the matching locations.  For each resolved location, you have
> a resolved line, resolved source file, resolved addr, resolved function, etc.

I understand (I think).  But all this does is fill in the attributes
that were missing from the input location spec.  This is done either
by using the (implied) defaults, like the name of the current file, or
bhy using the debug info.  And if it turns out that some attribute can
be filled in more than one way, we have a breakpoint with multiple
code locations.  Right?