From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id D3A4E3828928 for ; Fri, 27 May 2022 19:00:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D3A4E3828928 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37318) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nufCe-0002Yv-TD; Fri, 27 May 2022 15:00:53 -0400 Received: from [87.69.77.57] (port=4313 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 1nufCJ-0003Jo-8q; Fri, 27 May 2022 15:00:52 -0400 Date: Fri, 27 May 2022 22:00:27 +0300 Message-Id: <83mtf2n6lw.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: (message from Pedro Alves on Fri, 27 May 2022 19:50:58 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2022 19:00:56 -0000 > Date: Fri, 27 May 2022 19:50:58 +0100 > From: Pedro Alves > Cc: gdb-patches@sourceware.org > > BTW, my text says this: > > +The location spec may be incomplete, and @value{GDBN} will do its best > +to find all the locations in the program that match it. For example, > +a location spec may just indicate a line number and a source filename > ^^^^^^^^^^^^^^^ > +with no directory components, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > and this example too: > > +@item > +The location spec specifies a file name, and multiple files in the > +program share the same name. That's about location specs; I was talking about the code location, where the missing attributes need to be resolved. > IMO, from this it should be obvious that the code location has directory > components that you can match. I don't think I follow: match with what and in what way? Are you talking about "matching" of an absolute file name with relative file names? > The explicit locations section already says for example: > > @table @code > @item -source @var{filename} > The value specifies the source file name. To differentiate between > files with the same base name, prepend as many directories as is necessary > to uniquely identify the desired file, e.g., @file{foo/bar/baz.c}. Otherwise > @value{GDBN} will use the first file it finds with the given base > name. This option requires the use of either @code{-function} or @code{-line}. > > I'm not sure we want to go into details like that in the intro section. Users won't > be able to use any location spec format without reading the corresponding section, > so they'll see this. What I was talking about was not about using the location specs, it was about explaining what it is and how it differs from the code location. I think we have to explain the terminology before we use it, since it is not entirely trivial.