From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id jzI2LboekWLjuggAWB0awg (envelope-from ) for ; Fri, 27 May 2022 14:55:54 -0400 Received: by simark.ca (Postfix, from userid 112) id A85061E221; Fri, 27 May 2022 14:55:54 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=YGq0xoCV; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 0F3C81E01D for ; Fri, 27 May 2022 14:55:54 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4BB3A3828928 for ; Fri, 27 May 2022 18:55:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4BB3A3828928 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1653677753; bh=XQCoCZr975bjF1mginTwlJ75i7cFy+m2cii5/qD9Y1E=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=YGq0xoCVdWTQjpiycIATuNan85459MQjCAPvdHX7LbZIe0X+9g5CRTlBCYsIw4np9 7w5VaWLTSrsVUc64Yji6p0mN6ur6SiuTLIIXTUu09zdlLcjILeLrVGZ2mXghNvUZZP ufSC7/44tsNt9e+yQl4smCiGQmOEUMCW8A78hZ1Q= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 228EF385735C for ; 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 ) 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 ) 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> To: Pedro Alves 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-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > Date: Fri, 27 May 2022 19:42:50 +0100 > Cc: gdb-patches@sourceware.org > From: Pedro Alves > > > 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?