From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3371 invoked by alias); 6 May 2004 05:08:26 -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 3296 invoked from network); 6 May 2004 05:08:23 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 6 May 2004 05:08:23 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.30) id 1BLb7K-0003gY-Mq; Thu, 06 May 2004 01:08:18 -0400 Date: Thu, 06 May 2004 05:08:00 -0000 Message-Id: From: Eli Zaretskii To: Paul Koning CC: weigand@i1.informatik.uni-erlangen.de, orjan.friberg@axis.com, kettenis@chello.nl, gdb-patches@sources.redhat.com, drow@false.org In-reply-to: <16536.61374.770000.659411@gargle.gargle.HOWL> (message from Paul Koning on Wed, 5 May 2004 09:44:30 -0400) Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT Reply-to: Eli Zaretskii References: <200405042208.AAA07379@faui1d.informatik.uni-erlangen.de> <16536.61374.770000.659411@gargle.gargle.HOWL> X-SW-Source: 2004-05/txt/msg00149.txt.bz2 > Date: Wed, 5 May 2004 09:44:30 -0400 > From: Paul Koning > > Ulrich> We don't define target_stopped_data_address, and *cannot* do > Ulrich> so because the hardware doesn't provide this information. > > Neither does MIPS, unless you disassemble the trapping instruction to > deduce the address. That's what I've done in our MIPS remote gdb > stub. Would the suggested STOPPED_BY_WATCHPOINT patch work for the MIPS remote stub? > The trouble I ran into is that this doesn't work because (on remote > target support for MIPS anyway) the watchpoint handling does an > effective "stepi" after the watchpoint stop. After that stepi, > stopped_by_watchpoint() would return false because the most recent > stop was due to a break (the stepi). But that is something the target-side code could handle, right? I mean, stopped_by_watchpoint has intimate knowledge about the target's particulars, so it could fiddle the stop reason if it saw the indication that a watchpoint fired _and_ that the most recent stop was due to a single-step, right? Failing that, we could have something like AUTO_STEPI_AFTER_WATCHPOINT in higher-level code in GDB (infrun.c or breakpoint.c) to handle such targets, but I generally think that the GDB application-level code should not bother itself with target-specific peculiarities if we can avoid that.