From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by sourceware.org (Postfix) with ESMTPS id 736B03831283 for ; Wed, 25 May 2022 22:18:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 736B03831283 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-wm1-f54.google.com with SMTP id f23-20020a7bcc17000000b003972dda143eso1901374wmh.3 for ; Wed, 25 May 2022 15:18:05 -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=FHdU8ojFJLof9KRtW6RRbXzKlKf3FpTfLhuEjD9nvy8=; b=SF6Zusm9O8aaosbXNIVERlEUhnO+egghyEOMsGdcubBhTS8ddPtbOjbcePJlUg3QSL tJbeoDU3d38AYkXOUzI6w9H52v9K+ghIoVR8NMeL0CKPhMX09Ia2KJyesHKU4SiS+2gA UkoR7/RCGPZ6QZeFRo21iRTp4sBlGA/dREwAMSf2gAxjlCSfv6oOX2g9I4UFL2QFG9Jj /Y2VRDGlXALo80tVLlD3uFz1ZYLcmIdA7DdIoq208nCEBN9iTovlBJajDZrXOPuHJhmr HRJf+I96cOBn6VYq0Igija69cOSxfz5iizGW4hF6yBidZ8wP0ZajnxKc3GKNRUJiKTip gmAQ== X-Gm-Message-State: AOAM531nsJrrbUjWUR2ErpOQ/hhzUZwF3n/q3yS41Tvkv9Ye0NapAiep 6/Drvex2LNmD1bql8iEdxmpvWIgVmj8= X-Google-Smtp-Source: ABdhPJwUTxS85vVuwFFMa0Tx225dpHCEBommqngRrJQkwJrD44aV71vRHKvojbR48wW03H8cedxf3g== X-Received: by 2002:a7b:cb47:0:b0:393:dd9f:e64a with SMTP id v7-20020a7bcb47000000b00393dd9fe64amr9907458wmj.170.1653517084361; Wed, 25 May 2022 15:18:04 -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 v5-20020adfe285000000b0020e6470b2a7sm68555wri.85.2022.05.25.15.18.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 May 2022 15:18:03 -0700 (PDT) Message-ID: Date: Wed, 25 May 2022 23:18:02 +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] gdb/manual: Introduce locspecs Content-Language: en-US To: Philippe Waroquiers , Eli Zaretskii 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> From: Pedro Alves In-Reply-To: <90766c666b0108ea2ab8d298c82dd9004af49ed7.camel@skynet.be> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.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=no 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: Wed, 25 May 2022 22:18:09 -0000 On 2022-05-25 22:24, Philippe Waroquiers wrote: > On Wed, 2022-05-25 at 21:05 +0100, Pedro Alves wrote: >> On 2022-05-25 20:56, Eli Zaretskii wrote: >>>> From: Pedro Alves >>>> Date: Wed, 25 May 2022 20:31:26 +0100 >>>> >>>> To clarify this, I propose we use the term "Location Specification", >>>> with shorthand "locspec", when we're talking about the user input, the >>>> argument or arguments that is/are passed to commands to instruct GDB >>>> how to find locations of interest.  This is distinct from the actual >>>> locations in the program, which are what GDB finds based on the >>>> user-specified locspec.  Then use "locspec" thoughout instead of >>>> "location" when we're talking about the user input. >>> >>> Sorry, but I don't think this is a good idea.  It is IMO okay to >>> introduce "location specification" into our terminology; it is even >>> okay to use "location spec" as its shorthand.  But "locspec" is too >>> much: it's not a word, so it doesn't explain itself enough, and thus >>> cannot be used very far from where it is defined, because the reader >>> will likely not understand what it means. >> >> Yet, we have "linespec" and people understand it just fine, it's described >> once in a single spot in the manual.  "locspec" just sounds novel now, but it won't be >> novel anymore once we start using it.  It sounds like you are against any term that >> is new just because it is new.  That just blocks progress forever.  It is not reasonable. >> New shorthand names for for things that are referred very frequently should be fine >> to invent.  Our users aren't dummies and they learn things. > 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. I would find that really odd -- a breakpoint is passed a location specification, and then we plant a breakpoint instruction on each of the program locations that matches the specification. Each breakpoint location really represents a program location, with address, function, file and line all being important. So it's natural to call each of those a different location. I don't see why would we even bother to consider renaming breakpoint locations to something else. > > Why not then use breakpoint specification/bkptspec for the first concept > and location for the second ? "breakpoint specification" wouldn't work because we have many commands that take a location spec as argument that have nothing to do with breakpoints. For example: (top-gdb) info line main Line 365 of "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operators/char/2.cc" starts at address 0x86dee9 and ends at 0x86def1 . Line 73 of "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/substr/char/1.cc" starts at address 0x86c097 and ends at 0x86c09f . Line 62 of "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/rfind/char/3.cc" starts at address 0x86bd5a and ends at 0x86bd62 . Line 47 of "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/rfind/char/2.cc" starts at address 0x86b9a6 and ends at 0x86b9ae . ... (top-gdb) list -function main file: "/home/pedro/gdb/binutils-gdb/src/gdb/gdb.c", line number: 25, symbol: "main(int, char**)" 20 #include "main.h" 21 #include "interps.h" 22 23 int 24 main (int argc, char **argv) 25 { 26 struct captured_main_args args; 27 28 memset (&args, 0, sizeof args); 29 args.argc = argc; file: "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/capacity/1.cc", line number: 166, symbol: "selftests::string_view::capacity_1::main()" 161 VERIFY( sz03 >= sz04 ); 162 } 163 164 static int 165 main() 166 { 167 test01(); 168 169 return 0; 170 } ... (top-gdb) edit main Specified line is ambiguous: file: "/home/pedro/gdb/binutils-gdb/src/gdb/gdb.c", line number: 25, symbol: "main(int, char**)" file: "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/capacity/1.cc", line number: 166, symbol: "selftests::string_view::capacity_1::main()" file: "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/cons/char/1.cc", line number: 61, symbol: "selftests::string_view::cons_1::main()" file: "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/cons/char/2.cc", line number: 40, symbol: "selftests::string_view::cons_2::main()" file: "/home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/cons/char/3.cc", line number: 33, symbol: "selftests::string_view::cons_3::main()" ... Etc. Please take a look at the v2 patch I sent, and its description, where you'll find plenty of examples more. If you look at the patch's diff itself, you'll find I added text to several commands describing what they do when the spec matches multiple locations.