From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id tHwsN9HGb2NwnxcAWB0awg (envelope-from ) for ; Sat, 12 Nov 2022 11:16:17 -0500 Received: by simark.ca (Postfix, from userid 112) id D62241E124; Sat, 12 Nov 2022 11:16:17 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=hG1SajM1; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 2D1AA1E0CB for ; Sat, 12 Nov 2022 11:16:17 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2CB513841889 for ; Sat, 12 Nov 2022 16:16:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2CB513841889 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1668269776; bh=Yybk0jQ1dSUNnKKEnJ8cxXL1shUP1U9RRpAc16g0DmA=; h=Subject:To:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=hG1SajM1A9MxJMKawz7G7FcNf2BqPrYQXzNaIo0N4uxip4TcPV0rfn8O8IWJt1sL2 v4p+qVP5/poZi7iTJsuf6xvD8O/ZodT1CDS8KvxsJCS/hqQ6beMuXaPlYIsBCnXSN/ kTBvZcPCBxabL6z8PHPm6P9BmdY29Mg7wzHed/3k= Received: from mailsec117.isp.belgacom.be (mailsec117.isp.belgacom.be [195.238.20.113]) by sourceware.org (Postfix) with ESMTPS id 0462A387101B for ; Sat, 12 Nov 2022 16:15:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0462A387101B X-ExtLoop: 1 X-IPAS-Result: =?us-ascii?q?A2AtAQBfxm9j/1uGgG0NTYEJCYFGgy+BWIROkRoDgROQS?= =?us-ascii?q?ItVgX4PAQEBAQEBAQEBCTkLBAEBhQABAgEBAoR8JjYHDgECBAEBAQEDAgMBA?= =?us-ascii?q?QEBAQEDAQEGAQEBAQEBBgQBgRuFLzmCQikBg3QBAQEBAgEjBFcLCw0LAgImA?= =?us-ascii?q?gJXBgESgn6CfjaqHXp/MxpnhHGaZYFhBoEULIFmhxqDYIQwN4FVRIEVgnM3P?= =?us-ascii?q?oJiBBiBJAEBg3eCZwSXPxw4AxkrHUADC20NShtYDgkfHA4XDQUGEgMgbAUKN?= =?us-ascii?q?w8oL2cQGxwbB4EMKigVAwQEAwIGEwMiAg0pMRQEKRINKydvCQIDImUFAwMEK?= =?us-ascii?q?CwDCSEfBxYRJDwHVjoBBAMCECA4BgMJAwIkVHUuERUFAwsVJQgFSgQIOQUGU?= =?us-ascii?q?xICChEDEg8GJkUOSD45FgYndA4OFANegWkENZslghZgGScREC8pLX11oiufW?= =?us-ascii?q?TQHg2uBRwYMiXSVBzKXGAORe5c0II0jlHuFOoFpBYIJbVOCZ1KOVBYViE+FS?= =?us-ascii?q?3Q7AgcLAQEDCYp0AQE?= IronPort-PHdr: A9a23:2BTq/R+Bud9rdv9uWcC7ngc9DxPPW53KNwIYoqAql6hJOvz6uci4Y AqEtb490ReJBdydt6gfzbKO8ujJYi8p2d65qncMcZhBBVcuqP49uEgeOvODElDxN/XwbiY3T 4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6JvjvGo7Vks+7y/2+94fcbglWizexe71/I Ra5oQjStsQdnI9uJrosxhfTrXZEZepbyXl0KV6Pmhr3+9u98oNk/ylMofwq6tROUb/9f6Q2T LxYCCopPmUo78D1thfNUBWC6GIEXmoZjhRHDQ7F7ArnXpjqqSv1qvB92CiBMsLoS70/RCmv4 L1qSB/sjycHKiI5/WTKgcF+kK5XvBSsrAFkzoXKfI+aKuZxfqLFfdMbW2VBWNpRVzdcCY+4d ocDEvYNMfpdo4T7ulAArwaxBRO0Ce3s1zFGhmH406M43OQvDQ7J0gMvEd0VvXTIrtj4LrseX fyvwaTKyzjIcvNY2S366IjNah0vu/GMXbN0ccrQ0UkvDx3KhUiQpoP/JTOV0f0Ns3Wa7+V+T +KvkHMspgZpojivx8csjojJhpoNyl/a7yl4zpw6Jce/SE5ifN6kEYVftzuBN4ZtWcMiQGFpu CAkxb0ao5K0ZzYFxY0hyhXCZPOJb5KG7Qj/VOaNPzh4nnRldaqjixuu7USuyuzxWMa73VhFq idIndrBuHAQ2xDO68WLVuZx8Ee/1DqRyQze5O9KLE47m6fFKpMsw7o9mJoRvEnBGCL9hUv4j KiTdko+++io7fzqYq7hpp+BLY97lh/xM6o0lcylH+s0KA8OX3KU+em6ybbt/lX5Ta1XgvEql qTVqo3WKdoYq6KjHgNY3Iku5wy7Aju71tkTgGMJI0hfeB2diojkI1TOIPflAvihm1msizJrx +zePr3mH5XNMmDPkLf/crZ57E5R0A48wc1b6p5KEL0NPfP+V0zruNDFFBM1Lgi5zOD/BNV80 IMRR36PD7eEPK/OtVKE/P8jL/ePaYMPpTrwJfco6+TqgHMkgVMdeLOm3ZoTaHC2BPRmJECZb GL0gtcBEGcKugs+TPTyiFKcSzJSaWy9X7g75jEiFYKmDJnMRpq2gLGaxye7HZ1XZmZYBVCQC 3vnbJuLV+8KaC2JOsBhiCALVaC9S4890hGjrBH2x6J9LuXI4i0YqY7j1N9t6u3PkhEy8Cd5D 9iH02GKSmF7gGMJSyUq06B4pExx0k2D3rRgg/xECdxT4OtEUggnOpHH1uB6E8r9Wh7dcdeJV lmmWc6rASo2TtIs2d8Bf1hyGtu4gRDZwSWmGbgVl6aEBM98zqWJ43/0b/pnzHPLxeF1k14ja tdVMmirl+h08A2FQ8bxk0Sdlr6yeOwj1TTK7XqCwHCV9F9ZWUZfXa+ARXkDbUvbtpyt6U/IC qenFb8nPxBp0smfMKBHddTzgBNBXvi1a/rEZGfko2exAReQ3r7EU4PwfHwA3SjHEwBQiwAS+ XeeLQV4GS67pHvDDTF0Dnr0YFLq/PU4on7tHRx89B2Dc0A0j+n9wRUSn/HJDqpLhto5 IronPort-Data: A9a23:3Q9KK6gO3QxWreKbjfyDVeexX161IhEKZh0ujC45NGQN5FlHY01je htvWz2Ab/qONjP9fNBxb4Tg8UwDvpWBytBjSFZq+S1hFi5jpJueD7x1DKtQ0wB+jyHnZBg6h ynLQoCYdKjYdleF+lH3dOGJQUBUjcmgXqD7BPPPJhd/TAplTDZJoR94kobVuKYx6TSCK17L6 I2aT/H3Ygf/gWctazhMsMpvlTs21BjMkGJA1rABTa0T1LPuvyF9JI4SI6i3M0z5TuF8dgJtb 7+epF0R1jqxEyYFUrtJoJ6iGqE5auK60Ty1t5Zjc/PKbi6uCcAF+v1T2PI0MS+7gtgS9jx74 I0lWZeYEW/FMkBQ8QgQe0EwLs1wAUFJ0OD4JUXjodyB83L5L2LtxN5BPk4mAZJNr46bAUkWn RAZAANUP0rF3rzmhuv9E7hZ7ighBJCzbcVG4CEmlGqFS6d/KXzAa/yiCdtwxDcxgsFWBfuYe MMDbiNybRnaeDVUOUYRBY54lurAanzXKmEG8APE+vdmi4TV5C1eiOS3c//fQfmLX+Vbz3e8i lrA5F2sV3n2M/Tak1Jp6EmEmujKtT/hX4cfBfuz8fsCqFKfzCkLAQEdVVagieK+l1S1Vs1WM UFS/TAhxZXe72TyFoi7Bkfo5iff4lhNArK8DtEH1e1E8YKMiy7xO4TOZmcphAAO3CP9edDmO pJlUT8k6fyDfYB5kU6gy4o= IronPort-HdrOrdr: A9a23:QC83KqiazslOqiEXk+HtMS8nB3BQXtcji2hC6mlwRA09TyX4rb HLoB1/73TJYVkqNk3I9ersBED4exPhHP1OkOws1NWZNjUO0VHARL2Ki7GC/9SKIULDH4BmuZ uJdcBFeb/N5VwTt7eY3DWF X-IronPort-Anti-Spam-Filtered: true X-ProximusIPWarmup: true Received: from unknown (HELO [192.168.1.19]) ([109.128.134.91]) by relay.proximus.be with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Nov 2022 17:15:51 +0100 Message-ID: <48cdb20a40387a0dda02ada9d0fede9b8844b6ba.camel@skynet.be> Subject: Re: [RFAv3] Show locno for 'multi location' breakpoint hit msg+conv var $bkptno $locno. To: Tom Tromey , Philippe Waroquiers via Gdb-patches Date: Sat, 12 Nov 2022 17:15:51 +0100 In-Reply-To: <87a64yzttf.fsf@tromey.com> References: <20220606094504.744323-1-philippe.waroquiers@skynet.be> <87a64yzttf.fsf@tromey.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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: , From: Philippe Waroquiers via Gdb-patches Reply-To: Philippe Waroquiers Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On Thu, 2022-11-10 at 08:57 -0700, Tom Tromey wrote: > > > > > > "Philippe" == Philippe Waroquiers via Gdb-patches > > > > > > writes: > Philippe> Also, when a breakpoint is reached, the convenience variables > Philippe> $bkptno and $locno are set to the encountered breakpoint number > Philippe> and location number. > > I believe we have a convention that new internally-created convenience > variables will start with "_". > > I wondered a little whether we wanted to introduce $_bkptno or just > repurpose the already-existing $bpnum, but I see we already do this kind > of thing for tracepoints, and I suppose having different variables for > different semantics is good... it's just a bit unfortunate that the > names are similar. Re-using $bpnum was discarded as this would break existing scripts assuming $bpnum value is kept unchanged when a break is hit. Thinking again about the names, having $bpnum and $bkptno (or $_bkptno) is confusing. So, $_hit_bpnum and $_hit_locno for the 2 new variables seem more clear and more consistent. > > Note that the breakpoint number convenience variable is > https://sourceware.org/bugzilla/show_bug.cgi?id=12464, so this should > be in a Bug: trailer and also mentioned in the form "PR breakpoints/12464" > somewhere in the commit message. > > Philippe> +Inside a command list, you can use the command > Philippe> +@kbd{disable $bkptno} to disable the encountered breakpoint. > Philippe> + > Philippe> +If your breakpoint has several code locations, the command > Philippe> +@kbd{disable $bkptno.$locno} will disable the specific breakpoint code > Philippe> +location encountered. > > It may be worth mentioning that the $_bkptno.$_locno form will work even > when your breakpoint only has a single location, and also the ".1" > special case for single-location breakpoints. Will do. > > Philippe> @@ -8494,7 +8494,21 @@ print_stop_location (const target_waitstatus &ws) > Philippe> LOCATION: Print only location > Philippe> SRC_AND_LOC: Print location and source line. */ > Philippe> if (do_frame_printing) > Philippe> - print_stack_frame (get_selected_frame (NULL), 0, source_flag, 1); > Philippe> + { > Philippe> + if (tp->control.stop_bpstat != nullptr) > Philippe> + { > Philippe> + const struct breakpoint *b = tp->control.stop_bpstat->breakpoint_at; > Philippe> + > Philippe> + if (b != nullptr) > Philippe> + { > Philippe> + int locno = bpstat_locno (tp->control.stop_bpstat); > Philippe> + set_internalvar_integer (lookup_internalvar ("bkptno"), b- > >number); > Philippe> + set_internalvar_integer (lookup_internalvar ("locno"), > Philippe> + (locno > 0 ? locno : 1)); > > This is in print_stop_location - but what if the location is not > printed? > > I am curious if these variables can be, are intended to be, or should be > usable from breakpoint conditions or silent 'commands'. I think the semantic we want for these variables is to give the breakpoint number of the breakpoint that was just (or last) hit. I did not know about the "silent" breakpoint feature. IMO, it looks better to have these variables set for silent breakpoints as they should be available in the silent breakpoint command list. A condition evaluating to false means the breakpoint is not considered as hit (e.g. the nr of times a breakpoint is hit is only incremented and its commands are only run when the condition is true). Also, for some targets, the breakpoint condition are evaluated at the target side. So, it looks reasonable to me to only set these variables when a breakpoint is (really) hit, and not to set them when evaluating a breakpoint condition. > > I suspect maybe bpstat_do_actions_1 is a better spot for this, though > I'm not really sure. Effectively not very clear, in particular, when several breakpoints are set at the same place and when some or all of these breakpoints are silent. When several breakpoints are not silent, GDB prints only one of these. In this case, the variables should be set to the printed breakpoint. When all breakpoints are silent, I guess it is not important to choose a particular value. Waiting for a possible reply to this mail, I will start a new version of the patch based on the above Thanks Philippe