From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id F33273858434 for ; Thu, 26 May 2022 13:41:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F33273858434 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 2996D1E01D; Thu, 26 May 2022 09:41:32 -0400 (EDT) Message-ID: <196f6082-8f22-7a78-cd8e-817d706ad6b4@simark.ca> Date: Thu, 26 May 2022 09:41:31 -0400 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] gdb/manual: Introduce locspecs Content-Language: en-US To: Eli Zaretskii , Pedro Alves Cc: gdb-patches@sourceware.org References: <20220525193126.1613411-1-pedro@palves.net> <83mtf5perq.fsf@gnu.org> <0f341f7e-1eca-7087-495f-32f32fcc58e8@palves.net> <90766c666b0108ea2ab8d298c82dd9004af49ed7.camel@skynet.be> <83a6b4pz04.fsf@gnu.org> From: Simon Marchi In-Reply-To: <83a6b4pz04.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_PASS, 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 13:41:35 -0000 On 2022-05-26 02:51, Eli Zaretskii via Gdb-patches wrote: >> Date: Wed, 25 May 2022 23:18:02 +0100 >> Cc: gdb-patches@sourceware.org >> From: Pedro Alves >> >>> IIUC, Eli would like to have location reserved for a breakpoint giving multiple resulting >>> locations. >> >> No, he was saying he would prefer "location" to be reserved for location specifications, >> and to find a different name for breakpoint locations. > > Yes. > >> I don't see why would we even bother to consider renaming breakpoint >> locations to something else. > > Because we want to use "location" for location specifications, and I > would like us to avoid a confusing ambiguity. FWIW, I also think that it's clearer to keep "location" for the concrete, resolved locations in the program. "Location specification" makes sense as a new term for what you pass to the "break" command (and others). Simon