From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 6664B3858C52 for ; Mon, 10 Apr 2023 15:07:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6664B3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681139274; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ohWnyjmu0ZO3feFCE7iUxFu7GxlV8aNoVTvNK1wadQc=; b=PcIpjMOMUs7c7wVraek9fw7/STzKPuxzqT3bdCmTKOSMW5AUjJNZHLFWHq9pd7gktbRCth OsIVCvo0lO3StLg9y5I71ZLqcThrula8Kw3uFokaklXFUjZfCCZoZ7cuZAW1PKQ94sWBNa KXTtOQ3ETMrvYqL9JBIjBV12IK6AqsM= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-208-i3RuBEsxP-iaZWepvgHv7A-1; Mon, 10 Apr 2023 11:07:52 -0400 X-MC-Unique: i3RuBEsxP-iaZWepvgHv7A-1 Received: by mail-ed1-f69.google.com with SMTP id 4fb4d7f45d1cf-50480ce89a2so1100550a12.3 for ; Mon, 10 Apr 2023 08:07:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681139271; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=b87bIZglaBdbNITkmhFiGBOM4wxeHAF386rGqjl6ocs=; b=cPUYtSX3AD8VRlVnvt2MtEhd0VJHwdiKKnFR/B01rlXjsY/EjuYEa7JwcBpmZe/j7E 26UkCgDNVyFSoyD+ep6S5eIw0MPrayb04P+kkJoFB3Qb40qQB7Tz5sBfNX2YnxpcQVDk +vbef3r2Y2tXH5xKFojuWrKqioeKa1odMbwBoo7Sr1wQXuI8JQN8ZAJ/GkNTPDjf/8Pk filIM/aNlk4boP0hP3ySXyHJWVV/xKG7zLU2M3vQN+JPrDupdQlbX8Dcc8LEvATX/08g /SJFjKRSdNgagtJFZnmZfY4PnefOZ8CqLNdNEuSVBfYmezD1TC82r5dS0J49c/izob4B q8ZA== X-Gm-Message-State: AAQBX9eYtvfuCzCNwEOcyIPgEK9U3TMwOwRgBEvQVnt82yPg0lxUOsRZ UW+mmKc5iXfnWUSQT0/yv2DrIYDi8rwrthsnOTkb+lhzLDchdXJSXTguJfkLLR6zHhbhTZvbt6F lSkwSdpbTNduBG/etuL1UiFIUsimdEg== X-Received: by 2002:aa7:d94b:0:b0:504:b01c:cc53 with SMTP id l11-20020aa7d94b000000b00504b01ccc53mr1910035eds.1.1681139271554; Mon, 10 Apr 2023 08:07:51 -0700 (PDT) X-Google-Smtp-Source: AKy350bEldfNP5m5KuFhud9MJq5sySoDdJ2IPB8fTLN5Y/84diPl35nlvZ9bZUF2abQUqfmNECkaCw== X-Received: by 2002:aa7:d94b:0:b0:504:b01c:cc53 with SMTP id l11-20020aa7d94b000000b00504b01ccc53mr1910007eds.1.1681139271193; Mon, 10 Apr 2023 08:07:51 -0700 (PDT) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id a22-20020a509b56000000b005048c1f37b4sm2462787edj.64.2023.04.10.08.07.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Apr 2023 08:07:50 -0700 (PDT) From: Andrew Burgess To: Pedro Alves Cc: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [PATCH v2 1/2] Always show locations for breakpoints & show canonical location spec In-Reply-To: <9f7b3fba-f260-7901-ece0-51f377839733@palves.net> References: <20220519215552.3254012-1-pedro@palves.net> <20220519215552.3254012-2-pedro@palves.net> <834k1kd7ne.fsf@gnu.org> <625057b2-1691-a472-fa93-0dabacbddd39@palves.net> <83ilpv5bd3.fsf@gnu.org> <4c7a9504-83e0-6c02-fda6-0254ab4eede4@palves.net> <8335gwpiih.fsf@gnu.org> <83v8tsnxp6.fsf@gnu.org> <9f7b3fba-f260-7901-ece0-51f377839733@palves.net> Date: Mon, 10 Apr 2023 16:07:49 +0100 Message-ID: <877cujbwsa.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Pedro Alves writes: > On 2022-05-26 16:03, Eli Zaretskii wrote: >>> Date: Thu, 26 May 2022 15:04:21 +0100 >>> Cc: gdb-patches@sourceware.org >>> From: Pedro Alves >>> >>>> Yes, and that's the point I tried to make: you can enable or disable a >>>> breakpoint at some location, not enable/disable the location itself, >>>> which is what the text was saying. >>> >>> "enable or disable a breakpoint at some location" is slightly ambiguous= because >>> it doesn't distinguish between the whole breakpoint vs one individual l= ocation >>> the breakpoint is set at. >>=20 >> How so? it says "disable a breakpoint AT SOME LOCATION". IOW, the >> breakpoint is disabled/enabled only at some location. >>=20 >>>>> I really think that this is the wrong direction, and working on >>>>> the patch that I pointed at above really convinced me so even more. >>>>> I believe that that patch will convince you as well. Please take a l= ook >>>>> there. >>>> >>>> I did, and it didn't. It actually convinced me even more that we >>>> cannot use "location" in both contexts without creating confusion. >>> >>> What a mystery. The current text uses location throughout and it >>> isn't a problem. >>=20 >> I explained why in another message: we were using "location" in just >> one sense, now we are supposed to be using it in two senses: one for >> "specifying" a location, the other for the location itself. In many >> situations in life the thing and its specification are one and the >> same, or tightly coupled. E.g., we frequently say in the >> documentation of a program stuff like >>=20 >> This function deletes the specified FILE... >>=20 >> which doesn't distinguish between FILE and its specification. >>=20 > > A better example would be: > > This function deletes all files that match GLOB... > > and then what is a GLOB is described somewhere, and a glob is very > obviously different from the actual files the glob matches. > > >> We are now supposed to distinguish between a "location" and its >> "specification". This is not easy to do, and I think it risks >> creating a confusion. This is based both on experience with other >> things that are defined through some sort of "specification", and on >> actual reading the text of your patches. >>=20 > > I don't think it is, difficult. A spec looks like one of these strings: > > func > source:line > *expression > -source src -line l > -function func -label lab > > etc. You can't confuse this with an actual concrete location. A spec > resolves to locations. But it isn't itself a location. The documentatio= n > for each command doesn't say that currently, just uses @var{location}, bu= t > if you follow the xfer to the "Specify locations" node, it is clear there= . > > But we'll make it clearer, regardless. > >>=20 >>>> But now I'm beginning to wonder what is your definition of "location" >>>> in this context? What does it entail if two different "locations" can >>>> be resolved to the same code address? And where is that meaning of >>>> "location" described? The text you proposed uses "location(s) that >>>> match(es) the location spec", which doesn't seem to imply any >>>> attributes except the "place" where the breakpoint will be set, since >>>> "location spec" is just source-level description of one or more such >>>> "places". How does "location" imply anything about local variables, >>>> commands, etc.? >>> >>> A location is some actual place in the program, identifiable by >>> some "coordinates". Some source line in the program can be a location >>> in the program, if you have its coordinates. Line number alone isn't s= ufficient. >>> A source location is fully defined by the path to its file and the line= number, the >>> full prototype of its function, and the address of the first instructio= n that the line was >>> compiled down to. Addresses are per-inferior, so add inferior to the c= oordinate system. If >>> you have the same code loaded in multiple inferiors, GDB considers the = same code at each >>> address its own location. E.g. here's a breakpoint set at handle_infer= ior_event, with two inferior gdbs loaded: >>> >>> 3 breakpoint keep y =20 >>> 3.1 y 0x00000000004ea2ac in handle_inferior_= event(execution_control_state*) at /home/pedro/gdb/binutils-gdb/src/gdb/inf= run.c:5331 inf 1 >>> 3.2 y 0x00000000004ea2ac in handle_inferior_= event(execution_control_state*) at /home/pedro/gdb/binutils-gdb/src/gdb/inf= run.c:5331 inf 2 >>> >>> Note "inf 1" and "inf 2" on the right hand side. So you have two locat= ions for the same code, in two inferiors. >>=20 >> I don't think we have this described on this level of detail anywhere, >> do we? I think if we agree to use "source location" for this, we >> should have all of the above in the description of the term. >>=20 >>> You may not have debug info for all locations in the program. So a loc= ation >>> may be missing some coordinates, like the file/line. It won't be a sou= rce location, >>> but it is still some actual program location. Or you may lack the full= path >>> to the filename. Etc. But the tuple of the coordinates identify some = actual spot in >>> the actual program. Address alone isn't sufficient to identify source = location, >>> given inlining. Of course, if you don't have debug info, address is al= l you got. >>=20 >> So we can also have "incomplete" source locations, right? And the >> source location has some minimum set of attributes that _must_ be >> resolved in order for the source location to be valid, right? We >> should then document that as well, including the possibility of its >> being incomplete. >>=20 > > I documented all this in the Location Specifications section. I'll send = v4 in a bit. > > I did not go for "source locations", however. I swear I am not trying to= be > difficult... The issue is that as I tried to describe things, "source lo= cation" read > awkwardly, and kind of a lie-ish. Because, you can have usable resolved = locations without > sources, even if they are incomplete. It depends on command if they are = usable. Instead, I > noticed something. > > Here: > > * List:: Printing source lines > -* Specify Location:: How to specify code locations > +* Location Specifications:: How to specify code locations > ^^^^^^^^^^^^^^ > > And note what the intro paragraph of that node currently says: > > "Several GDB commands accept arguments that specify a location or locat= ions of your program=E2=80=99s code." > > Clearly the arguments specify something, and that something is ... "locat= ions of your program=E2=80=99s code." > > So I went with "code locations" instead. I actually first started by usi= ng "program location" > throughout, or "location in your program", but then as I polished, and po= lished, and > polished, I ended up using "code location" everywhere. I think it reads = really nicely. > Code location is nice for being a superset of "resolved complete source l= ocation" and "resolved location > that is just some address and maybe function name" (because we don't have= debug info). It fits both. > > I also went through all the command's documentation again, looked at the = code for each, > checking what exactly GDB looks for in the resolved locations, and switch= ed the manual > to refer to resolved lines or resolved addresses etc. Very similar to yo= ur earlier comments, > except that by switching to use "resolved to" instead of "matches", it no= w looks better > to me too this way. For example: > > +@itemx info line @var{locspec} > Print the starting and ending addresses of the compiled code for > -source line @var{location}. You can specify source lines in any of > -the ways documented in @ref{Specify Location}. With no @var{location} > -information about the current source line is printed. > +source lines that @var{locspec} resolves to. @xref{Location > +Specifications}, for the various forms of @var{locspec}. > +With no @var{locspec}, information about the current source line is > +printed. > > @kindex info macros > -@item info macros @var{location} > -Show all macro definitions that are in effect at the location specified > -by @var{location}, and describe the source location or compiler > -command-line where those definitions were established. > +@item info macros @var{locspec} > +Show all macro definitions that are in effect at the source line > +@var{locspec} resolves to, and describe the source location > +or compiler command-line where those definitions were established. > > etc. > > For the case where you wanted to add @var{addr}, I removed > the parenthesis from the sentence, like: > > -We can also inquire (using @code{*@var{addr}} as the form for > -@var{location}) what source line covers a particular address: > +We can also inquire, using @code{*@var{addr}} as the form for > +@var{locspec}, what source line covers a particular address > +@var{addr}: > > Oh, and for the "source lines" ambiguity in the "list command", I tweaked= it > by saying something else other than "ambiguous locations". Like so: > > + If either > +@var{first} or @var{last} resolve to more than one source line in the > +program, then the list command will show the list of resolved source > +lines and does not proceed with the source code listing. > > The trick is to say "source code listing" instead of "print source lines"= . > > > I did a lot of small changes here and there throughout... > > Anyhow, you'll see in v4 in a bit. Hi Pedro, I was doing some work in the 'info breakpoints' area, and remembered this patch. Was this something you're still working on? Thanks, Andrew