From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id BIAGMNztlGJPQQkAWB0awg (envelope-from ) for ; Mon, 30 May 2022 12:16:28 -0400 Received: by simark.ca (Postfix, from userid 112) id B579F1E221; Mon, 30 May 2022 12:16: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=wVUuNghy; 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 06D331E01D for ; Mon, 30 May 2022 12:16:28 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 18821384B123 for ; Mon, 30 May 2022 16:16:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 18821384B123 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1653927387; bh=p5A2XJ1prkda5zWgYF12CD0Cb6fEmv/TtJiWKUhlGjs=; 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=wVUuNghyOVY73VQyVTbmoRtbRbs0xRInwkqWdl9wXoHcBYI7cfFLVZlUQyG7BySxO hWUOTTniKyRhe71+9t4r6p/UKhQ9chV5fZBFIVqDO+WiExUJpNk+ZYb5p89hyxCXcr eATZdPP2SbIpEqbpKzy/FZ/9hDlpjnVp1WKG4VSQ= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 265FD3857025 for ; Mon, 30 May 2022 16:15:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 265FD3857025 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41700) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nvi3F-0000QH-89; Mon, 30 May 2022 12:15:29 -0400 Received: from [87.69.77.57] (port=2970 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 1nvi2q-00087d-IV; Mon, 30 May 2022 12:15:20 -0400 Date: Mon, 30 May 2022 19:15:06 +0300 Message-Id: <837d63j8tx.fsf@gnu.org> To: Pedro Alves In-Reply-To: <6914f754-4e33-5aa1-4ea6-dca9504e8bfe@palves.net> (message from Pedro Alves on Mon, 30 May 2022 15:44:59 +0100) Subject: Re: [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> 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: Mon, 30 May 2022 15:44:59 +0100 > Cc: gdb-patches@sourceware.org > From: Pedro Alves > > >> -@item clear @var{location} > >> -Delete any breakpoints set at the specified @var{location}. > >> -@xref{Specify Location}, for the various forms of @var{location}; the > >> -most useful ones are listed below: > >> +@item clear @var{locspec} > >> +Delete breakpoints with code locations that match @var{locspec}. > > ^^^^^^^^^^^^^^^^^^^^^^^^ > > "that are the result of resolving @var{locspec}" > > That wouldn't actually be correct for this command. For example: > > (top-gdb) b gdb.c:29 > Breakpoint 4 at 0x555555641091: file /home/pedro/gdb/binutils-gdb/src/gdb/gdb.c, line 29. > (top-gdb) b *0x555555641092 > Breakpoint 5 at 0x555555641092: file /home/pedro/gdb/binutils-gdb/src/gdb/gdb.c, line 29. > (top-gdb) info breakpoints > Num Type Disp Enb Address What > 4 breakpoint keep y 0x0000555555641091 in main(int, char**) at /home/pedro/gdb/binutils-gdb/src/gdb/gdb.c:29 > 5 breakpoint keep y 0x0000555555641092 in main(int, char**) at /home/pedro/gdb/binutils-gdb/src/gdb/gdb.c:29 > > "gdb.c:29" resolves to address 0x0000555555641091, as can be seen when breakpoint 4 was > created. However, this: > > (top-gdb) clear gdb.c:29 > Deleted breakpoints 4 5 > > ... also deletes breakpoint 5. GDB deleted it because its code location also matches > the user input. But then "matches locspec" is also inaccurate, and for the same reason: they are two equivalent ways of describing the same process of arriving at a code location from a location spec, or at least that's how the text used them until now. > This is explained just a bit below, here: > > @item clear @var{linenum} > @itemx clear @var{filename}:@var{linenum} > Delete any breakpoints set at or within the code of the specified > @var{linenum} of the specified @var{filename}. > @end table > > Key here are "or within the code", and talking about the _specified_ > linenum/filename, not the resolved line/filename. Then we need some change of text to the same effect where "clear LOCSPEC" is described, right? > >> +Here are examples of typical situations that result in a location spec > >> +matching multiple concrete code locations in your program: > > > > Should we also enumerate some situations where a location spec cannot > > be completely resolved? The text talks about that possibility, but > > only in passing, with no details or practical examples. > > I've added these examples under the multi-location examples: > > +And here are examples of typical situations that result in a location > +spec matching no code locations in your program at all: > + > +@itemize @bullet > +@item > +The location spec specifies a function name, and there are no > +functions in the program with that name. > + > +@item > +The location spec specifies a source file name, and there are no > +source files in the program with that name. > + > +@item > +The location spec specifies both a source file name and a source line > +number, and even though there are source files in the program that > +match the file name, none of those files has the specified line > +number. > +@end itemize Shouldn't this mention explicitly the frequent situation where the location specifies something in a yet-unloaded shared library? > >> +register other than the program counter. If @var{locspec} resolves to > >> +an address in a different function from the one currently executing, the > >> +results may be bizarre if the two functions expect different patterns > >> +of arguments or of local variables. For this reason, the @code{jump} > >> +command requests confirmation if the specified line is not in the > >> +function currently executing. ^^^^ > > > > "line" or "code location"? > > I think it should say "jump address" here instead of "specified line", as this is > not about a line the user input in the spec, but rather what address the locspec > resolved to. So perhaps it's better to say "if @var{locapsec} resolves to an address that is not in the currently executing function". > /* See if we are trying to jump to another function. */ > fn = get_frame_function (get_current_frame ()); > sfn = find_pc_function (sal.pc); > if (fn != NULL && sfn != fn) > { > if (!query (_("Line %d is not in `%s'. Jump anyway? "), sal.line, > fn->print_name ())) > { > error (_("Not confirmed.")); > > The query talks about "Line", but the check isn't comparing lines, this > query will trigger even if you try to jump to a function without line info. > That query's text should be fixed too, IMO. Yes. > >> +@item break-range @var{start-locspec}, @var{end-locspec} > >> +Set a breakpoint for an address range given by @var{start-locspec} and > >> +@var{end-locspec}, which are location specs. @xref{Location > >> +Specifications}, for a list of all the possible forms of location > >> +specs. If either @var{start-locspec} or @var{end-locspec} resolve to > >> +multiple addresses in the program, then the command aborts with an > >> +error without creating a breakpoint. The breakpoint will stop > >> +execution of the inferior whenever it executes an instruction at any > >> +address within the specified range, including @var{start-locspec} and > >> +@var{end-locspec}. > > > > This deviates from the usual practice elsewhere, and talks about > > location specs resolving into _addresses_ and not code locations. is > > that intentional and necessary? > > Yes, it is intentional here, because the command is exactly about breaking > on any address that falls within an address range. Then I think this needs some additional text explaining that, or qualifying the "location resolves to address" part. Thanks.