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 5829238133FA for ; Fri, 27 May 2022 14:16:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5829238133FA Received: from fencepost.gnu.org ([2001:470:142:3::e]:57394) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nual6-0004H5-Lp; Fri, 27 May 2022 10:16:08 -0400 Received: from [87.69.77.57] (port=2564 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 1nual6-0003Xd-59; Fri, 27 May 2022 10:16:08 -0400 Date: Fri, 27 May 2022 17:16:03 +0300 Message-Id: <8335gvnjrw.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: <20220526194250.2310460-1-pedro@palves.net> (message from Pedro Alves on Thu, 26 May 2022 20:42:50 +0100) Subject: Re: [PATCH v4] gdb/manual: Introduce location specs References: <20220526194250.2310460-1-pedro@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 14:16:12 -0000 > From: Pedro Alves > Date: Thu, 26 May 2022 20:42:50 +0100 > > gdb/doc/gdb.texinfo | 419 +++++++++++++++++++++++++------------------- > gdb/doc/guile.texi | 2 +- > gdb/doc/python.texi | 5 +- > 3 files changed, 246 insertions(+), 180 deletions(-) Thanks. The changes in descriptions of the commands that accept location specs seem more-or-less okay, although I didn't yet read all of them in detail (so please don't push just yet). The "Location Specifications" section, OTOH, needs more work. I didn't yet make up my mind regarding what exactly should it look like, and one reason why I'm not there yet is that your text doesn't seem to describe the "code location" in full: > +A concrete code location in your program is uniquely identifiable by a > +set of logical attributes. Typically, a line number, the source file > +the line belongs to, the fully-qualified and prototyped function it is > +defined in, and an instruction address. Because each inferior has its > +own address space, also an inferior number. The "typically" part and the overall style seem to say that this is not the exhaustive list of all the attributes of a code location, just a general idea. Can you please present a full exhaustive list of the attributes of a code location? And another question: does the process of resolving a location spec to obtain the corresponding code locations involve only filling in of the attributes that were omitted from the spec, or does it also produce attributes that can _never_ be part of the location spec? IOW, can the user type a location spec which will yield a code location that is 100% identical to the input spec? IMO, the best way to describe "location specifications", "code locations", and how the former leads to the latter depends on the answers to those two questions. Thanks.