From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Tb88GT/dkGJ7sggAWB0awg (envelope-from ) for ; Fri, 27 May 2022 10:16:31 -0400 Received: by simark.ca (Postfix, from userid 112) id 57DEB1E221; Fri, 27 May 2022 10:16:31 -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=ekNC72NC; 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 DFBAE1E00D for ; Fri, 27 May 2022 10:16:30 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 34CFB396E82F for ; Fri, 27 May 2022 14:16:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 34CFB396E82F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1653660990; bh=HOm/z9z5kA2NQ8y84u5NelBHYBVza17pQhqkOak/uYM=; 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=ekNC72NCD6GvgRAw8U4gts1shpwR05UfUjKr2O4LHYzNMhh+S/uAfzbaEUzo4apW9 9Vrx6FovWR+6keYd7U0tQim/KC8WMB0fUrWRTGogcztDnTfEZFCzn+BPsZ4852NYlv uQThKVyNAOFJNVCfVZwgIpFkxktBFvagZdR0qBpY= 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> To: Pedro Alves 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-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" > 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.