From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28208 invoked by alias); 30 Nov 2001 18:33:46 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 28184 invoked from network); 30 Nov 2001 18:33:43 -0000 Received: from unknown (HELO mirapoint.inter.net.il) (192.114.186.20) by hostedprojects.ges.redhat.com with SMTP; 30 Nov 2001 18:33:43 -0000 Received: from zaretsky ([192.116.55.139]) by mirapoint.inter.net.il (Mirapoint) with ESMTP id BBE29989; Fri, 30 Nov 2001 20:33:32 +0200 (IST) Date: Thu, 22 Nov 2001 13:19:00 -0000 From: "Eli Zaretskii" To: orjan.friberg@axis.com Message-Id: <5137-Fri30Nov2001203301+0200-eliz@is.elta.co.il> X-Mailer: emacs 21.1.50 (via feedmail 8 I) and Blat ver 1.8.9 CC: gdb-patches@sources.redhat.com In-reply-to: <3C07B6FE.BBFA048D@axis.com> (message from Orjan Friberg on Fri, 30 Nov 2001 17:42:38 +0100) Subject: Re: Hardware watchpoints; dealing with false triggers? Reply-to: Eli Zaretskii References: <3C07B6FE.BBFA048D@axis.com> X-SW-Source: 2001-11/txt/msg00410.txt.bz2 > Date: Fri, 30 Nov 2001 17:42:38 +0100 > From: Orjan Friberg > > Maybe I should clarify that I'm not talking about the x86, but a > hypothetical target whose watchpoint mechanism would function this way. Yes, I guessed that much. > > > Now, say a there's a read of wp1's byte 0. The hardware would trigger, > > > but it would be a false trigger. Gdb would somehow have to find out the > > > actual address that was read and if it was found to be outside of the > > > variable's range it would not trigger the watchpoint. > > > > You can't do that, at least not with x86 debug registers: when a > > watchpoint triggers, you don't know what byte of its covered memory was > > written to. All you know is that memory covered by a specific register > > was written. > > Ok, but say that the actual address is shipped with the register packet > when the target stops so that gdb in fact knows what address was > actually read/written. I'm thinking gdb could compare that address with > the watchpoints, and just send the target on its way if the address is > outside the watched ranges. This can be done. The low-level target end is repsonsible to tell GDB whether a watchpoint triggered, and at what address. So given enough information from your target, you could write the low-level watchpoint code to DTRT. > And this is the key issue: could the interface to the target-specific > code be extended to handle the concept of "actual watchpoint address"? We already have this: it's called target_stopped_data_address. breakpoint.c uses this macro to see which watchpoint, if any, triggered. From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eli Zaretskii" To: orjan.friberg@axis.com Cc: gdb-patches@sources.redhat.com Subject: Re: Hardware watchpoints; dealing with false triggers? Date: Fri, 30 Nov 2001 10:33:00 -0000 Message-ID: <5137-Fri30Nov2001203301+0200-eliz@is.elta.co.il> References: <3C07B6FE.BBFA048D@axis.com> X-SW-Source: 2001-11/msg00625.html Message-ID: <20011130103300.vJNvd3MdicI7U75cL4u2y8MQGw0h593U-84DNYPZOQY@z> > Date: Fri, 30 Nov 2001 17:42:38 +0100 > From: Orjan Friberg > > Maybe I should clarify that I'm not talking about the x86, but a > hypothetical target whose watchpoint mechanism would function this way. Yes, I guessed that much. > > > Now, say a there's a read of wp1's byte 0. The hardware would trigger, > > > but it would be a false trigger. Gdb would somehow have to find out the > > > actual address that was read and if it was found to be outside of the > > > variable's range it would not trigger the watchpoint. > > > > You can't do that, at least not with x86 debug registers: when a > > watchpoint triggers, you don't know what byte of its covered memory was > > written to. All you know is that memory covered by a specific register > > was written. > > Ok, but say that the actual address is shipped with the register packet > when the target stops so that gdb in fact knows what address was > actually read/written. I'm thinking gdb could compare that address with > the watchpoints, and just send the target on its way if the address is > outside the watched ranges. This can be done. The low-level target end is repsonsible to tell GDB whether a watchpoint triggered, and at what address. So given enough information from your target, you could write the low-level watchpoint code to DTRT. > And this is the key issue: could the interface to the target-specific > code be extended to handle the concept of "actual watchpoint address"? We already have this: it's called target_stopped_data_address. breakpoint.c uses this macro to see which watchpoint, if any, triggered.