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.