From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fllv0015.ext.ti.com (fllv0015.ext.ti.com [198.47.19.141]) by sourceware.org (Postfix) with ESMTPS id 0A1003858283 for ; Sun, 7 Aug 2022 06:25:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0A1003858283 Received: from fllv0035.itg.ti.com ([10.64.41.0]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 2776PvjQ123572 for ; Sun, 7 Aug 2022 01:25:57 -0500 Received: from DFLE102.ent.ti.com (dfle102.ent.ti.com [10.64.6.23]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 2776Pviu113434 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sun, 7 Aug 2022 01:25:57 -0500 Received: from DFLE104.ent.ti.com (10.64.6.25) by DFLE102.ent.ti.com (10.64.6.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Sun, 7 Aug 2022 01:25:57 -0500 Received: from DFLE104.ent.ti.com ([fe80::44c:e883:6f6f:384d]) by DFLE104.ent.ti.com ([fe80::44c:e883:6f6f:384d%17]) with mapi id 15.01.2308.014; Sun, 7 Aug 2022 01:25:57 -0500 From: "Denio, Mike" To: "gdb@sourceware.org" Subject: RE: Confused by watchpoints on remote protocol Thread-Topic: Confused by watchpoints on remote protocol Thread-Index: Adip1GWVQGgzoEbbTR20UHUTp2psZAAUaSQQ Date: Sun, 7 Aug 2022 06:25:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.59.181] x-exclaimer-md-config: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, MANY_SPAN_IN_TEXT, 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2022 06:26:00 -0000 You can ignore my second question in the original e-mail. I was not reporti= ng the stop correctly. GDB behavior was as expected once I fixed that. The only question I have is that when I type: "watch *(uint32_t *)(0x80000018)" I get a hardware watch point. And when I type: "watch (uint32_t)ram_table" I get a software watch point. Anyone know why? And how to change it to be always hardware? Thanks, Mike From: Denio, Mike <> Sent: Saturday, August 06, 2022 3:43 PM To: 'gdb@sourceware.org' Subject: Confused by watchpoints on remote protocol In GDB 11.2 for RISCV, I am trying to support hardware watchpoints. I think= I'm close, but I have 2 questions: 1. I noticed that whether or not GDB will even attempt to use a hardware wa= tch point depends on the how the command it entered. For example: (gdb) watch *(uint32_t *)(0x80000018) Hardware watchpoint 1: *(uint32_t *)(0x80000018) (gdb) watch (uint32_t)ram_table Watchpoint 2: (uint32_t)ram_table (gdb) i b Num Type Disp Enb Address What 1 hw watchpoint keep y *(uint32_t *)(0x80000018) 2 watchpoint keep y (uint32_t)ram_table When I enter is as "watch *(uint32_t *)(0x80000018)", a hardware watchpoint= is used, but when I enter it as "watch (uint32_t)ram_table", a soft watchpoint is used. I don't understand this. How can I tell GDB to always use a hardware watchp= oint? Also, FYI, the order doesn't matter (it's not as if GDB assumes only 1 hard= ware watchpoint). Below we see GDB immediately uses a software watchpoint: (gdb) watch (uint32_t)ram_table Watchpoint 1: (uint32_t)ram_table (gdb) watch *(uint32_t *)(0x80000018) Hardware watchpoint 2: *(uint32_t *)(0x80000018) (gdb) i b Num Type Disp Enb Address What 1 watchpoint keep y (uint32_t)ram_table 2 hw watchpoint keep y *(uint32_t *)(0x80000018) Now that I think about it, how do I tell GDB how many hardware watchpoints = I support? 2. Also a second related question. I noticed that unlike breakpoints, GDB w= ill not remove, single step past, and then replace hardware watchpoints. Is= it always assumed that hardware watchpoints break AFTER the operation in q= uestion? It makes sense to break after the operation for writes since the u= ser wants to watch a value change, but it wasn't obvious to me for read and= access watchpoints. Should all of them break on the following instruction? Thanks in advance for any help. Please keep my e-mail on the reply as I am = not subscribed. Mike