From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4529 invoked by alias); 27 Jan 2004 15:01: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 4519 invoked from network); 27 Jan 2004 15:01:54 -0000 Received: from unknown (HELO smtp.mba.ocn.ne.jp) (210.190.142.172) by sources.redhat.com with SMTP; 27 Jan 2004 15:01:54 -0000 Received: from localhost (p6068-ipad27funabasi.chiba.ocn.ne.jp [220.107.197.68]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id B5B48347E; Wed, 28 Jan 2004 00:01:52 +0900 (JST) Date: Tue, 27 Jan 2004 15:01:00 -0000 Message-Id: <20040128.000717.126570739.anemo@mba.ocn.ne.jp> To: drow@mvista.com Cc: gdb-patches@sources.redhat.com Subject: Re: mips gdbserver reports R0 != 0 From: Atsushi Nemoto In-Reply-To: <20040127141718.GA22917@nevyn.them.org> References: <20040127.193715.116346446.nemoto@toshiba-tops.co.jp> <20040127141718.GA22917@nevyn.them.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg00695.txt.bz2 >>>>> 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. 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. --- Atsushi Nemoto