From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id p5SRF8ijmGL54gkAWB0awg (envelope-from ) for ; Thu, 02 Jun 2022 07:49:28 -0400 Received: by simark.ca (Postfix, from userid 112) id 510D11E221; Thu, 2 Jun 2022 07:49:28 -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=ZrasZN0G; 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=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.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 AD3D51E143 for ; Thu, 2 Jun 2022 07:49:27 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0AC70395C42F for ; Thu, 2 Jun 2022 11:49:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0AC70395C42F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1654170567; bh=r6AKtEuog6rq5EoUP888PZb4/vWa73miT4tvEL9ZyS8=; 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=ZrasZN0Gdb3CJO5tc+rB8PV0ReePuX3kJaMm01XiAIiMLN3BP2DQA9Ul/d+3X8N5O 0z6XXnKaHyX6ig0u6bSeBzOZK9bitv8clokNbYBMRTaWnbl1wL5r0LiygftaVPlCoe K/T5lhxYw1bQoULGLGzWuZgm0uLBfNxKF2yBI4Uw= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 78007395C001 for ; Thu, 2 Jun 2022 11:49:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 78007395C001 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55266) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nwjK6-0007s9-Sa; Thu, 02 Jun 2022 07:49:06 -0400 Received: from [87.69.77.57] (port=2540 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 1nwjK6-0004cf-BS; Thu, 02 Jun 2022 07:49:06 -0400 Date: Thu, 02 Jun 2022 14:49:16 +0300 Message-Id: <834k13ffpf.fsf@gnu.org> To: Pedro Alves In-Reply-To: (message from Pedro Alves on Thu, 2 Jun 2022 12:10:54 +0100) Subject: Re: RTe: Location Specs (Was: [pushed v5] gdb/manual: Introduce location specs) References: <20220526194250.2310460-1-pedro@palves.net> <838rqmm7gb.fsf@gnu.org> <6914f754-4e33-5aa1-4ea6-dca9504e8bfe@palves.net> <83wne0fgmd.fsf@gnu.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: , 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: Thu, 2 Jun 2022 12:10:54 +0100 > Cc: gdb-patches@sourceware.org > From: Pedro Alves > > > A concrete code location in your program is uniquely identifiable by a > > set of several attributes: its source line number, the name of its > > source file, the fully-qualified and prototyped function in which it > > is defined, and an instruction address. Because each inferior has its > > own address space, the inferior number is also a necessary part of > > these attributes. By contrast, location specs you type will many > > I built the manual here with the patch, to read in the html form in the browser, > and found this paragraph very long and dense. I find it much more readable if we have a > paragraph break here (line break + empty line), before "By contract". Above we talk > about actual code locations. And below we talk about location specs. Sure, breaking there is fine, thanks. > > Several @value{GDBN} commands accept arguments that specify a location > > or locations of your program's code. Since @value{GDBN} is a > > source-level debugger, a location specification usually indicates some > > -line in the source code, but it can also indicate a function name, an > > -address, a label, and more. > > +line in some source file, but it can also do that indirectly, by > > +specifying a function name, an address, a label, etc. > > This is changing the meaning of what was said. It is now reading as if > the line number is what are are after, and that function, address, etc. > are merely means to get to the line number. While before, we were saying that > usually you specify the line number, but you can also specify some > function, or even a precise address. The new text gives a lot more emphasis to > the resolved line number. I didn't say "number", though, I just said "line". That's different: since GDB is a source-level debugger (as the text says), the location spec identifies some line in the source code. But it doesn't necessarily do that via its number. The point of that paragraph, as I interpret it, is to say that a function name, a label, or an address all identify a certain line in the source. > I think it's a difference in the interpretation of "indicate". The original > text uses it to mean the arguments the user can specify (otherwise it wouldn't > be talking about "a label" or function _name_), while in your version you seem > to be using "indicate" to mean the line number you want the spec to resolve to. > > There are commands that accept location specs and want to resolve them to > addresses, others to lines, etc., and you can specify a line to find the address, > and conversely you can also specify an address to find a line. > > Maybe we should say _that_ somehow, instead of the "Since @value{GDBN} is a > source-level debugger, a location specification usually indicates some > line" sentence, which I find kind of an unnecessary assertion. Specifying > function names to break at the function's entry is very usual too, for example. I'm not sure I understand the issue. "Indicates" was in your original wording: Several @value{GDBN} commands accept arguments that specify a location or locations of your program's code. Since @value{GDBN} is a source-level debugger, a location specification usually indicates some line in the source code, but it can also indicate a function name, an address, a label, and more. The changes I made to these two sentences are really exceedingly minor, so I wonder how could they change the meaning. Could you point to the modifications which change the meaning? If you meant what the user specifies, then I agree that perhaps "indicate" is not the best word, but I didn't interpret the above as alluding to what the user specifies, I interpreted it to what the user _means_ by the spec: the user always means some source-code level location. > > @item > > For a C@t{++} constructor, the @value{NGCC} compiler generates several > > -instances of the function body, used in different cases. > > +instances of the function body, used in different cases, but their > > +source-level names are identical, unless you qualify them. > > What do you mean by "qualify" here? The "fully-qualified and prototyped function" part. > Otherwise this looks great! Thanks.