From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id rWa8HhJb72KTJSIAWB0awg (envelope-from ) for ; Sun, 07 Aug 2022 02:26:26 -0400 Received: by simark.ca (Postfix, from userid 112) id 6FB0D1EA05; Sun, 7 Aug 2022 02:26:26 -0400 (EDT) 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=NEi29T7z; 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=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.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 179B01E797 for ; Sun, 7 Aug 2022 02:26:26 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2F03438582A2 for ; Sun, 7 Aug 2022 06:26:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2F03438582A2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1659853585; bh=pXl7P2aUQvv+kW782rK4xOWWylFaoBPJwRwUWy6Wbqo=; h=To:Subject:Date:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=NEi29T7zmWUezQZuwLZ2SMyRS/GLv+QWZH981qWSNn/H1Zjbg9Pw05E8g9FcdfIkS vFE80RYqxti8L6yQzOGJjtYgxGlSRAXeug9ZkHR7hdhW1h0AybOwuYS2+KNJiQEOBN i/0M4OAMN/ttBVFIHuWXPw5LwBzL/7x0Oj+ny7p0= 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 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 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: , From: "Denio, Mike via Gdb" Reply-To: "Denio, Mike" Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" 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