From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7091 invoked by alias); 15 Mar 2004 21:35:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6882 invoked from network); 15 Mar 2004 21:35:55 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 15 Mar 2004 21:35:55 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i2FLZt07004149 for ; Mon, 15 Mar 2004 16:35:55 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i2FLZtj09546 for ; Mon, 15 Mar 2004 16:35:55 -0500 Received: from localhost.localdomain (vpn50-70.rdu.redhat.com [172.16.50.70]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i2FLZs4q027690 for ; Mon, 15 Mar 2004 16:35:55 -0500 Received: from saguaro (saguaro.lan [192.168.64.2]) by localhost.localdomain (8.12.10/8.12.10) with SMTP id i2FLZncG017911 for ; Mon, 15 Mar 2004 14:35:49 -0700 Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Kevin Buettner To: gdb-patches@sources.redhat.com Subject: Re: [RFC] breakpoint.c: Don't let adjust_breakpoint_address() adjust watchpoints Message-ID: <20040315143549.600814b6@saguaro> In-Reply-To: <8011-Mon15Mar2004230512+0200-eliz@elta.co.il> References: <20040315133002.0d21df91@saguaro> <8011-Mon15Mar2004230512+0200-eliz@elta.co.il> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00338.txt.bz2 Message-ID: <20040319000900.BWwKl8LI8Asf4vfhSrw33Y0ml9b3HZhv3J3bojWFWKY@z> On Mon, 15 Mar 2004 23:05:13 +0200 "Eli Zaretskii" wrote: > > Date: Mon, 15 Mar 2004 13:30:02 -0700 > > From: Kevin Buettner > > > > In the course of running the GDB testsuite on FR-V, I discovered that it's > > a bad idea to adjust watchpoint addresses. If any adjustment is done, the > > watchpoint ends up at the wrong address. The patch below simply disables > > adjustment for watchpoints and some eventpoints. > > I'd like to hear more details. When do we need to adjust the > breakpoint address, for starters? We have some documentation about this in gdbint.texinfo: The FR-V target (see @file{frv-tdep.c}) requires this method. The FR-V is a VLIW architecture in which a number of RISC-like instructions are grouped (packed) together into an aggregate instruction or instruction bundle. When the processor executes one of these bundles, the component instructions are executed in parallel. In the course of optimization, the compiler may group instructions from distinct source statements into the same bundle. The line number information associated with one of the latter statements will likely refer to some instruction other than the first one in the bundle. So, if the user attempts to place a breakpoint on one of these latter statements, @value{GDBN} must be careful to @emph{not} place the break instruction on any instruction other than the first one in the bundle. (Remember though that the instructions within a bundle execute in parallel, so the @emph{first} instruction is the instruction at the lowest address and has nothing to do with execution order.) The FR-V's @code{ADJUST_BREAKPOINT_ADDRESS} method will adjust a breakpoint's address by scanning backwards for the beginning of the bundle, returning the address of the bundle. So, on FR-V, we were scanning backwards from the position of a watchpoint, looking for the start of a VLIW instruction. Given that watchpoints are usually set on data, this makes very little sense. Even when it might (sort of) make sense, we don't want to do any adjustment. E.g, if we were watching a specific executable location - perhaps it was being mysteriously modified - we wouldn't want to adjust the location of the watchpoint. The reason is that we're viewing that executable location as data. We want to be informed when that location changes, not some location (which represents the start of the VLIW location) before it. To make this more concise, it makes sense to adjust breakpoint addresses, because the architectural constraint is related to the placment of breakpoints in executable code. It doesn't make sense to do this kind of adjustment on watchpoints since watchpoints are concerned with data related accesses. The other client of TARGET_ADJUST_BREAKPOINT is PPC. It uses the breakpoint adjustment mechanism to dereference function descriptors. I think my proposed change makes sense for this case as well. I.e, we don't want to prevent the user from putting a watchpoint on a function descriptor. As things stand now, that is what would happen. Kevin