From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5168 invoked by alias); 6 Mar 2012 20:20:11 -0000 Received: (qmail 5110 invoked by uid 22791); 6 Mar 2012 20:20:03 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Mar 2012 20:19:50 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1S50rN-0006HM-B8 from Maciej_Rozycki@mentor.com ; Tue, 06 Mar 2012 12:19:49 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 12:19:47 -0800 Received: from [172.30.11.135] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Tue, 6 Mar 2012 20:19:47 +0000 Date: Tue, 06 Mar 2012 20:20:00 -0000 From: "Maciej W. Rozycki" To: Pedro Alves CC: Subject: Re: [PATCH] remote: Fix hw watchpoint address matching In-Reply-To: <4F565A23.1070009@redhat.com> Message-ID: References: <201112071724.06407.pedro@codesourcery.com> <201112091415.08804.pedro@codesourcery.com> <4F565A23.1070009@redhat.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-03/txt/msg00206.txt.bz2 On Tue, 6 Mar 2012, Pedro Alves wrote: > > Back to this change, was distracted by something else. > > > So was I. :-) And more so, I would imagine -- I'll be missing you and your expertise as a colleague, although I am happy we can still meet and work together from time to time here. > > Yes, this is about watchpoints, not breakpoints. ;) > > > I fully understand that. What I was saying is that if that is a concern, > then breakpoints with bit #31 set are quite likely to suffer from exactly > the same issue, with the remote possibly reporting the trapped address as > truncated to 32 bits or as a properly sign-extended 64-bit value. And I'd > imagine the code that handles the low level traps/exceptions to handle > both watchpoint and breakpoint addresses the same, and the stub code that > marshals those breakpoint addresses to rsp to be just as susceptible to > the issue as code that marshals watchpoint addresses. Now, I'm not > saying we should run to fix that... > > I'm still curious why isn't bkpt_breakpoint_hit broken like I described > above, when a breakpoint is subject to adjustment, such as > that done by mips_breakpoint_from_pc. I probably need to stare more > at the code. ;-) My understanding of how breakpoints work is the remote stub does nothing specific to report to GDB that it actually has hit a breakpoint. All it does is it reports a(n unspecified) debug trap, no different to one reported for single-stepping for example. Then GDB examines the value of the PC reported in the stop reply packet, or, in the absence of one, it retrieves the value of that register via an ordinary access, to see if it corresponds to a breakpoint address it knows. All of this goes through the regular register cache and any necessary sign- or zero-extension, as appropriate, is made for each architecture in a generic way by the backend involved. As I don't remember offhand I'd have to wade through code to track where exactly it actually happens, but I am fairly sure it's there. If that didn't work, then I would expect GDB to be completely unusable for the target affected and therefore easily noticed -- unlike this watchpoint corner case. > > Umm, there aren't that many comments of this kind there actually... > > > We started enforcing that rule not too long ago. Good choice, though you can certainly understand the rule isn't obvious from code itself yet. ;) > Anyway, thanks for the fixes, and congratulations on your new role. :-) Thanks. Maciej