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 E23713858C33 for ; Tue, 9 May 2023 18:26:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E23713858C33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [172.16.0.192] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (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 672011E0D4; Tue, 9 May 2023 14:26:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1683656803; bh=w1DL7ghdOvPI4yFwuCXG/T2qKg9vrTArbNhs4D/sie4=; h=Date:Subject:To:References:From:In-Reply-To:From; b=QenwOgw4wDAddMO/yDXGlSDLEaP4peqTk5pT2ToL6D18lLKOCdAkhJk4XVJ6u4KpJ 0pfXctns+4Y8GsLKjsxbwx3h78SVaM4agxV0NQuRncv2w7PVJ0OUkkkOVEiPmuTCr3 BqqrP2wuwOZGYYlDrFTM/G1VVdqygptiRkejrHs4= Message-ID: Date: Tue, 9 May 2023 14:26:42 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: Differences in MI Breakpoint Notification for GDB CLI and MI Command Content-Language: fr To: "bilal@siemens.com" , "gdb-patches@sourceware.org" References: From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.0 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 List-Id: On 5/9/23 11:29, bilal--- via Gdb-patches wrote: > Hi expert, > > I have noticed differences in the MI breakpoint notification when creating a breakpoint from the GDB CLI command versus using the MI command > > > If I create a software breakpoint for a read-only memory location using the GDB CLI command, GDB immediately notifies the MI client of a breakpoint modification by changing it to a hardware breakpoint. > i.e > $ ./arm-none-eabi-gdb -q /tmp/test --interpreter mi3 -ex "mem 0x0 0x100000 ro nocache" > =thread-group-added,id="i1" > ~"Reading symbols from /tmp/test...\n" > (gdb) > b main > &"b main\n" > ~"Breakpoint 1 at 0x254\n" > =breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00000254",at="",thread-groups=["i1"],times="0",original-location="main"} > =breakpoint-modified,bkpt={number="1",type="hw breakpoint",disp="keep",enabled="y",addr="0x00000254",at="",thread-groups=["i1"],times="0",original-location="main"} > ~"Note: automatically using hardware breakpoints for read-only addresses.\n" > ^done > (gdb) > > > However, there is no such notification if I use the MI break-insert command instead of the CLI command. > i.e > $ ./arm-none-eabi-gdb -q /tmp/test --interpreter mi3 -ex "mem 0x0 0x100000 ro nocache" > =thread-group-added,id="i1" > ~"Reading symbols from /tmp/test...\n" > (gdb) > -break-insert main > ~"Note: automatically using hardware breakpoints for read-only addresses.\n" > ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00000254",at="",thread-groups=["i1"],times="0",original-location="main"} > (gdb) > > > GDB only emits a modified notification when a breakpoint is hit, and an MI client, such as CDT, needs to re-install the breakpoint as a hardware breakpoint while the program is running and being debugged. Therefore, the IDE must first interrupt the program and then re-install the modified breakpoint. > > Could anyone explain why GDB does not emit an MI breakpoint notification when the breakpoint is first inserted? I'm guessing that it's because all MI notifications (the things starting with =_) are muted during the execution of the -break-insert command. The reason being that the client doesn't need to get notified of the breakpoint creation for its own -break-insert command. At first glance, it looks like a bug, the ^done response should probably say type="hw breakpoint". Simon