From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by sourceware.org (Postfix) with ESMTPS id B7D1938327CD for ; Thu, 26 May 2022 20:40:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B7D1938327CD 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-f52.google.com with SMTP id f2so3538145wrc.0 for ; Thu, 26 May 2022 13:40:41 -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=mgynLKc452zsjNTYDNXRQk6IiRfbnbbLQtU4P8azWIo=; b=pKfguv4fSHVw5CjlI0jKfDmlkiGI0LUnc/8wowE5jr0WJLasrlps5EPpdZMPvYGUpe BXk6+FsPT6KpBCRVmwzlz0FuObJ9El+pM0n3zvQX/fln5WNUVDGSxxj4VUuiFeO+zF2O KChiGPZ2gipsGt6jTZUIcXetJz/ls7mi/R5JFXQ8e7O6MC51hkurBpjL3a7jGywu04md KbQL9SmM7mUqApXZI4L+pkQjUTL+Id98p3dgCJZD2cqJMTH8JVWj9KVoQ0ggU2z0hsNC uDHBOoXigPXtJoYQ5lf1mLrojsVl8vHR1Qc4xoY0mIm6WQG6LvtYdttw68t5Oc9EkJvo KOCA== X-Gm-Message-State: AOAM532y19QrD376QvK1ys3Ly7g2QkZi9/NEDgZaKYAeKJ9o5eVYWE0s /GWlonSQepzCov4rK7ywdIoa1xFO9JA= X-Google-Smtp-Source: ABdhPJxLr2KkYYB+fBuWuDVDtt2iVTeG1/F2BlWxp9k4XU6pzZgn66gz6LcEaAou3hcpgsKJ2m1vuQ== X-Received: by 2002:a05:6000:246:b0:20f:fff4:e1ec with SMTP id m6-20020a056000024600b0020ffff4e1ecmr7630790wrz.485.1653597640762; Thu, 26 May 2022 13:40:40 -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 r2-20020a7bc082000000b0039744664af7sm231186wmh.1.2022.05.26.13.40.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 May 2022 13:40:39 -0700 (PDT) Message-ID: Date: Thu, 26 May 2022 21:40:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH v2 1/2] Always show locations for breakpoints & show canonical location spec Content-Language: en-US To: Eli Zaretskii Cc: gdb-patches@sourceware.org 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> <83k0a8nk5t.fsf@gnu.org> From: Pedro Alves In-Reply-To: <83k0a8nk5t.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Thu, 26 May 2022 20:40:43 -0000 On 2022-05-26 20:55, Eli Zaretskii wrote: >> Date: Thu, 26 May 2022 20:29:50 +0100 >> Cc: gdb-patches@sourceware.org >> From: Pedro Alves >> >> 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 location" 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 locations of your program’s code." >> >> Clearly the arguments specify something, and that something is ... "locations of your program’s code." >> >> So I went with "code locations" instead. > > I could agree with this, but note that you are contradicting yourself: > "code" can and is sometimes interpreted as "machine code", and thus > "code location" can be interpreted as "address", something you didn't > want. I didn't want "address" specifically, because it is either incorrect or misleading. E.g., "info macro" doesn't work with addresses, but you had suggested to say "address" for this one at some point. I was also worried with "addresses that match locspec", as it is sort of ambiguous with address locations. Breakpoints are set with the complete location coordinate, just the address is not enough to identify the location properly, given inlining. Explaining what "code location" means in the location specification chapter and talking about locspecs resolved to addresses, works, but just plain address doesn't. > By contrast, "source location" is unequivocally a source-level > concept, and reflects the fact that it refers to a certain line of > source code in a certain file. Moreover, it follows the example of > that C++ page you yourself used as an argument. Why now you deviate > from all that is a mystery for me. I pointed at the C++ page as an argument for the word "location", which you so strongly wanted to replace by something else, like "place" or "address" or some other unknown term. I had never understood that you would be fine with a qualifier on top of location. I wish I had known earlier. It's great we managed to meet in the middle somewhere. > > But if you don't care about all these inconsistencies, "code location" > is fine with me, as it qualifies the overly-general "location" enough > to solve the potential ambiguity, which was what bothered me. Great, let's go with it. > >> Anyhow, you'll see in v4 in a bit. >> >> I hope you will be happy with this one. > > Thanks. Looking forward for a review.