From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16654 invoked by alias); 27 Jan 2004 17:12:07 -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 16628 invoked from network); 27 Jan 2004 17:12:06 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 27 Jan 2004 17:12:06 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AlWku-00030g-RJ; Tue, 27 Jan 2004 12:12:04 -0500 Date: Tue, 27 Jan 2004 17:12:00 -0000 From: Daniel Jacobowitz To: Atsushi Nemoto Cc: gdb-patches@sources.redhat.com Subject: Re: mips gdbserver reports R0 != 0 Message-ID: <20040127171204.GA6369@nevyn.them.org> Mail-Followup-To: Atsushi Nemoto , gdb-patches@sources.redhat.com References: <20040127.193715.116346446.nemoto@toshiba-tops.co.jp> <20040127141718.GA22917@nevyn.them.org> <20040128.000717.126570739.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040128.000717.126570739.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00699.txt.bz2 On Wed, Jan 28, 2004 at 12:07:17AM +0900, Atsushi Nemoto wrote: > >>>>> On Tue, 27 Jan 2004 09:17:18 -0500, Daniel Jacobowitz said: > > >> I could not see the reason (maybe regcache?), but this patch fixed > >> my problem. > > drow> Did it fix the stepping problem, or did it fix the value > drow> displayed for $zero? > > Both. My stepping problem is triggered by wrong $zero value. I tried > with 'set debug remote 1' and found gdb inserted breakpoint at wrong > place when stepping 'beqz' instruction. Oh, I see how this happens now. Thanks for the explanation; in that case something definitely needs to be done. > drow> The register at that address is actually a saved flag used for > drow> syscall restarting. I have some local patches to support it > drow> properly, but I haven't had time to do anything with them :( > drow> Partly because of the number of gross hacks involved. > > The 'that address' means &pt_regs->regs[0] in kernel, right? > > I had not noticed that. Thank you. So my patch is not correct. > > Maybe the correct fix is clearing register cache in > new_register_cache(). I will try later. Explicitly zeroing the register cache should fix this, so I'd be happier with that solution. [Do you have a copyright assignment on file for GDB, btw? If not, I'll make the patch myself for you to test, to spare us the legal dance.] -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer