From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.hgst.iphmx.com (esa1.hgst.iphmx.com [68.232.141.245]) by sourceware.org (Postfix) with ESMTPS id 0118E398E48D for ; Thu, 18 Jun 2020 11:03:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0118E398E48D IronPort-SDR: 0pNAwLCzYKc7ARPIArJLK3zv0IUeLaU5UGRcYiGJ9HCTI3Etd5/L2Ej8l0tIiw4U1xJv21DmxR X21j+gjKf89lgsVW2Bje2/K3g9ojovL5C1bUtYgR5Xgb26XeGIpDOrdvO//0mkV0RZ/PH9C9cT vidaSYSm/IoF3xfo46xwP1JklDLuTHboJ2h8hO5BSEtiEZSHKf1+ugnDl+8Phc7bQAHdUk6XGr X9gMchougGyclZKc6p9bgkLolAMn7VbUKcu3/dhPb3pXe+dnGGLRpuIgB1vor35j/RRiQ2/SB0 kCU= X-IronPort-AV: E=Sophos;i="5.73,526,1583164800"; d="scan'208";a="249490973" Received: from h199-255-45-14.hgst.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 18 Jun 2020 19:03:49 +0800 IronPort-SDR: T+kp6PPgWIUzqG6fS03nmg9nCWPUEffaVRab2llYaI6EZXZzA5GB+bEMnSyhxWeWDJA7tDXcxt yfjTucoeF4fornUKVirfAkUH5yBlw/KhU= Received: from uls-op-cesaip01.wdc.com ([10.248.3.36]) by uls-op-cesaep01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jun 2020 03:53:02 -0700 IronPort-SDR: eMVGa5sqt18dMGtCzDe1KbU7nx4yqqiJ4vBooeIzd8iYYD59GN9E3HtV+vKf0tn/nNhMfHn5mF Pq5VYiAoNzwg== WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jun 2020 04:03:49 -0700 Date: Thu, 18 Jun 2020 12:03:46 +0100 (BST) From: "Maciej W. Rozycki" To: "Metzger, Markus T" cc: Simon Marchi , Shahab Vahedi , Luis Machado , "gdb@sourceware.org" , Shahab Vahedi Subject: RE: Why enforcing sw_breakpoint_from_kind() implementation in GDBserver targets In-Reply-To: Message-ID: References: <20200610174702.GA3486@gmail.com> <8f80e486-cca4-819b-7316-329832df985f@simark.ca> <20200611094048.GA1270@gmail.com> <07362b1e-3b9b-a858-ce7a-9a27daff511a@linaro.org> <20200611110053.GD1270@gmail.com> <335e5978-4893-b355-69cd-98a101f8dd2e@simark.ca> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: Thu, 18 Jun 2020 11:03:59 -0000 Hi Markus, > > > That's the only kind of breakpoint this architecture supports. As far as I > > understand, > > > the kind is per-target and used to distinguish different kinds of breakpoints > > supported > > > by this target. > > > > From your description I infer you do have different kinds of breakpoints, > > one (or more?) for each instruction. > > OK, one could view it that way that we have a separate breakpoint instruction > for each instruction/operand combination. > > I rather view it as a bit inside every instruction. Sure, that's fine, especially from the hardware's point of view. However for the purpose of the RSP abstraction I think my alternative point of view does make sense. > > > The points I was trying to make is that we're also using gdbarch breakpoints > > and that > > > in order to use z packets, we'd need insert_point() to be able to store shadow > > copies. > > > I have not looked into that since gdbarch breakpoints worked for me and would > > also > > > allow sharing the code between a native target and gdbserver. > > > > Why do you need to store any copy in `gdbserver'? GDB keeps a record of > > replaced instructions, so you can use it instead. Just send the original > > instruction as the breakpoint kind. > > The breakpoint kind would depend on the ISA. And we'd have a real lot of them. Well, that's just one interpretation. The breakpoint kind is really a generic cookie each target is free to give any interpretation to. There is no processing of this data I know of in common GDB or `gdbserver' code. > I don't think that we'd want to encode the original instruction in the breakpoint > kind. That's what the shadow copy inside the breakpoint object is for. I thought you wrote you had had to choose not to use `z0'/`Z0' packets due to the inability to utilise the breakpoint bits this way. Maybe I got this wrong. Maciej