From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24597 invoked by alias); 24 Jul 2006 21:46:02 -0000 Received: (qmail 24587 invoked by uid 22791); 24 Jul 2006 21:46:02 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Mon, 24 Jul 2006 21:46:00 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G58FR-0004zj-Tn; Mon, 24 Jul 2006 17:45:57 -0400 Date: Mon, 24 Jul 2006 21:46:00 -0000 From: Daniel Jacobowitz To: Roger Sayle Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Correct irix5-nat.c's fetch_core_registers Message-ID: <20060724214557.GA18918@nevyn.them.org> Mail-Followup-To: Roger Sayle , gdb-patches@sourceware.org References: <20060724194914.GD13612@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00367.txt.bz2 On Mon, Jul 24, 2006 at 03:03:23PM -0600, Roger Sayle wrote: > The current implementation in fetch_core_registers has two main > clauses. The first which currently reads "core_reg_size == > deprecated_register_bytes ()" really expects deprecated_register_bytes > to return 568, or 8*NUM_REGS are explained in the original post. This is the part at which your logic breaks down. Remember this one for a moment... > The good news is I think I may be able to get O32 to work. Turns > out in O32 core files, core_reg_size=284 (which is conveniently > 4*NUM_REGS). It also looks like when working on an O32 executable, > mips_isa_regsize is 4 (even on my MIPS4 box). So this aspect of > the logic seems simple enough, even though I'm not sure how much > other support would need to be added to GDB to finish an O32 port. ...and then look at this. At one point, at least, the first branch was taken for both o32 and n64. If you look at the code in that branch, this seems fairly sensible. What is probably confusing you is the mips_isa_regsize bits. They're much more recent than the rest of the code, so don't read too much into them; and they were added mechanically. Registers 0 - NUM_REGS are represented in the register cache as having mips_isa_regsize bytes, which is not necessarily the same as the ABI regsize. You can just accomodate that here. If the core register set size matches the ISA register size, just read them in. It should match. You can check and warn if they don't. IOW I think the entire else branch is dead; it reads in four bytes of N32 64-bit registers. Not very useful! -- Daniel Jacobowitz CodeSourcery