From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11996 invoked by alias); 6 May 2004 13:44:09 -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 11947 invoked from network); 6 May 2004 13:44:07 -0000 Received: from unknown (HELO sadr.equallogic.com) (66.155.203.134) by sources.redhat.com with SMTP; 6 May 2004 13:44:07 -0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i46Di6Zh030870 for ; Thu, 6 May 2004 09:44:07 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i46Di4nC030865; Thu, 6 May 2004 09:44:04 -0400 Received: from PKONING.equallogic.com ([172.16.1.103]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 May 2004 09:44:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16538.16676.33000.80626@gargle.gargle.HOWL> Date: Thu, 06 May 2004 13:44:00 -0000 From: Paul Koning To: eliz@gnu.org Cc: weigand@i1.informatik.uni-erlangen.de, orjan.friberg@axis.com, kettenis@chello.nl, gdb-patches@sources.redhat.com, drow@false.org Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT References: <200405042208.AAA07379@faui1d.informatik.uni-erlangen.de> <16536.61374.770000.659411@gargle.gargle.HOWL> X-OriginalArrivalTime: 06 May 2004 13:44:04.0566 (UTC) FILETIME=[32408760:01C43370] X-SW-Source: 2004-05/txt/msg00150.txt.bz2 >>>>> "Eli" == Eli Zaretskii writes: >> 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). Eli> But that is something the target-side code could handle, right? Eli> I mean, stopped_by_watchpoint has intimate knowledge about the Eli> target's particulars, so it could fiddle the stop reason if it Eli> saw the indication that a watchpoint fired _and_ that the most Eli> recent stop was due to a single-step, right? Eli> Failing that, we could have something like Eli> AUTO_STEPI_AFTER_WATCHPOINT in higher-level code in GDB Eli> (infrun.c or breakpoint.c) to handle such targets, but I Eli> generally think that the GDB application-level code should not Eli> bother itself with target-specific peculiarities if we can avoid Eli> that. I'd have to do a bunch of memory refreshing to remind myself of the various possibilities you're talking about... History: I started from a remote stub that was very poorly implemented, and handled things by faking a single-step locally. This was extremely ugly. I observed that gdb had machinery to handle all this cleanly from the gdb end, so I turned it on. And sure enough, it worked for some cases. But not for all, for the reasons I mentioned. I then looked for a way to fix that with minimal perturbation to the existing machinery. My conclusion was: the bug is that the internally generated stepi causese the "stopped by watchpoint" status and associated address to be forgotten, so the best fix is not to forget them. That's what I did. The other bug was that the break/watch point list traversal routine would mishandle some cases where no match was found, which is why I changed that area, again trying to do minimal change to the logic and fixing only the place where the code didn't do what the apparent intent was. As for gdb not doing target-specific peculiarities -- I'd say that HAVE_NONSTEPPABLE_WATCHPOINTS is the way to pass that knowledge around. Having it where it lives today is clean because (as far as I can tell) it puts the necessary special handling near where break/watch/step live. Trying to do it further down means you end up replicating a lot more of the magic involved in stepping. The mess I started out with (stepi "implemented" at the remote stub, transparent to gdb) convinced me of this. paul