From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by sourceware.org (Postfix) with ESMTPS id DB7E6395A05F for ; Fri, 27 May 2022 15:04:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DB7E6395A05F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f46.google.com with SMTP id t13so6222786wrg.9 for ; Fri, 27 May 2022 08:04:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=dHADczXVv70x+PfLrc3DzTdMh7nfsdPhQJz6t09++Us=; b=niU136LXpGbQqXG4BLDUPaGchYf7mjzPUooVPxyT6BbSQMIEmBsSwgbxN+S6vrHZzY T2jeMLZSJ2mklZrwI3y8w3VhH1pdUKKN1ronuHPAuwj5NZH5BiLyeMtttLXHIoFrk1hV mjV51PJf3qnbsslRwMPhDJrBBozEB29kzD0L887c5oReXYRWYcF/6U//L33UaxC3Tyo1 xhRw60GUwVYVU5yT06iH14Yf66zS86tBXUoFFQoVYkbxfKj7BQVWwfrDV3O3n4biUllM jEXknMX7YXYYZ1E4u1qezv4GqZbiaAXqk8IIwLw5MaJ+4enRcLyvOSa3uiEz4nZzZxyQ PpFg== X-Gm-Message-State: AOAM531S9qKo0x9fbg+wHoHt5xHI6FFGUY9ef6vYhy6bu9139ud43zEz +JpytpZ8wvjsvi0MekNZ8DBpAJEATDM= X-Google-Smtp-Source: ABdhPJx9xj0o8IZsSABkrdhmVT1Pscg0JEEMOEQa9+Z+Xi46iGoaAioZTOXxVSyOntDpstk9aRGH6Q== X-Received: by 2002:a5d:6488:0:b0:203:b628:70d2 with SMTP id o8-20020a5d6488000000b00203b62870d2mr35877879wri.83.1653663876590; Fri, 27 May 2022 08:04:36 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id f5-20020a0560001a8500b002101f90001csm1061255wry.11.2022.05.27.08.04.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 May 2022 08:04:35 -0700 (PDT) Message-ID: <956e1fbd-5f03-c021-c390-82e1cf3493b5@palves.net> Date: Fri, 27 May 2022 16:04:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v4] gdb/manual: Introduce location specs Content-Language: en-US To: Eli Zaretskii Cc: gdb-patches@sourceware.org References: <20220526194250.2310460-1-pedro@palves.net> <8335gvnjrw.fsf@gnu.org> From: Pedro Alves In-Reply-To: <8335gvnjrw.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 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 15:04:39 -0000 On 2022-05-27 15:16, Eli Zaretskii wrote: >> 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? I meant to remove the "typically", and forgot it, sorry. It is not supposed to be there. > > 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? Currently there's no way to explicitly specify the inferior with any format of location specifications. So if you do "b func", and you have multiple inferiors, GDB will find code locations for "func" in all the inferiors. All the other attributes you can explicitly specify. Not sure whether that answers your question. I am not sure what you mean by "100% identical". A spec can never the identical to the actual thing, the same way a cake recipe can never be identical to a cake, for they are things of different nature. It can only be that the actual thing complies with or follows the 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. >