From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15356 invoked by alias); 20 Apr 2009 21:15:05 -0000 Received: (qmail 15282 invoked by uid 22791); 20 Apr 2009 21:15:02 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail3.caviumnetworks.com (HELO mail3.caviumnetworks.com) (12.108.191.235) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Apr 2009 21:14:53 +0000 Received: from exch4.caveonetworks.com (Not Verified[192.168.16.23]) by mail3.caviumnetworks.com with MailMarshal (v6,2,2,3503) id ; Mon, 20 Apr 2009 17:14:54 -0400 Received: from exch4.caveonetworks.com ([192.168.16.23]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 14:14:51 -0700 Received: from dd1.caveonetworks.com ([64.169.86.201]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 14:14:51 -0700 Message-ID: <49ECE5CB.6000708@caviumnetworks.com> Date: Mon, 20 Apr 2009 21:15:00 -0000 From: David Daney User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Pedro Alves CC: gdb-patches@sourceware.org Subject: Re: [Patch 1/2] Fix aftermath of 'infrun.c support for MIPS hardware watchpoints.' References: <49D9AECB.7040302@gmail.com> <200904171443.26794.pedro@codesourcery.com> <49ECBF74.8020306@caviumnetworks.com> <200904202007.37943.pedro@codesourcery.com> In-Reply-To: <200904202007.37943.pedro@codesourcery.com> Content-Type: multipart/mixed; boundary="------------060307020406070301050607" X-IsSubscribed: yes 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: 2009-04/txt/msg00543.txt.bz2 This is a multi-part message in MIME format. --------------060307020406070301050607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 754 Pedro Alves wrote: > > In the mean time, your patch is OK. I'd just move the > registers_changed call to *after* target_resume, because the > target_resume implementation could trigger a register cache > refetch, thus reintroducing the problem (e.g., it doesn't happen > on mips *today*, but see e.g., i386-linux-nat.c:i386_linux_resume). I'd > put it right after the prepare_to_wait call. > >> 2009-04-20 David Daney >> >> * infrun.c (handle_inferior_event): Move registers_changed call down. >> This is the version I committed. Thanks for taking the time to review these. 2009-04-20 David Daney * infrun.c (handle_inferior_event): Move registers_changed call down. --------------060307020406070301050607 Content-Type: text/plain; name="infrun.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="infrun.patch" Content-length: 719 Index: infrun.c =================================================================== RCS file: /cvs/src/src/gdb/infrun.c,v retrieving revision 1.368 diff -u -p -r1.368 infrun.c --- infrun.c 14 Apr 2009 00:59:47 -0000 1.368 +++ infrun.c 20 Apr 2009 21:06:10 -0000 @@ -2842,10 +2842,10 @@ targets should add new threads to the th if (!HAVE_STEPPABLE_WATCHPOINT) remove_breakpoints (); - registers_changed (); /* Single step */ hw_step = maybe_software_singlestep (current_gdbarch, read_pc ()); target_resume (ecs->ptid, hw_step, TARGET_SIGNAL_0); + registers_changed (); waiton_ptid = ecs->ptid; if (HAVE_STEPPABLE_WATCHPOINT) infwait_state = infwait_step_watch_state; --------------060307020406070301050607--