From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19556 invoked by alias); 25 Mar 2005 05:49:27 -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 19250 invoked from network); 25 Mar 2005 05:49:19 -0000 Received: from unknown (HELO priv-edtnes57.telusplanet.net) (199.185.220.220) by sourceware.org with SMTP; 25 Mar 2005 05:49:19 -0000 Received: from takamaka.act-europe.fr ([142.179.108.108]) by priv-edtnes57.telusplanet.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050325054918.WTYX25142.priv-edtnes57.telusplanet.net@takamaka.act-europe.fr> for ; Thu, 24 Mar 2005 22:49:18 -0700 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 02EBE47DC0; Thu, 24 Mar 2005 21:49:17 -0800 (PST) Date: Fri, 25 Mar 2005 05:49:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: Re: [RFC/mips] Problem with fetching/setting 32 bit registers Message-ID: <20050325054917.GC32590@adacore.com> References: <20050324041407.GG1324@adacore.com> <20050324042630.GA1262@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050324042630.GA1262@nevyn.them.org> User-Agent: Mutt/1.4i X-SW-Source: 2005-03/txt/msg00309.txt.bz2 Daniel, > This appears to be a bug in your native support, at least relative to > the rest of the MIPS port. Thanks to your help, I think I actually better what happens, now. It's a size issue: fpregsetp->fp_csr is 32bits long, while the value stored int the raw part of the regcache is 64 bits. So when we do the memcpy inside regcache_raw_supply(), we end up copying the FSR register value at the first 4 bytes of the regcache buffer, and then some other junk. When comes the time to transform this raw register into a cooked register, we naturally look at the last 4 bytes... I am currently testing the attached patch. Doesn't it look better? Thanks, -- Joel Index: irix5-nat.c =================================================================== RCS file: /gnat.dev/cvs/Dev/gdb/gdb-6.3/gdb/irix5-nat.c,v retrieving revision 1.2 diff -u -p -r1.2 irix5-nat.c --- irix5-nat.c 18 Nov 2004 10:49:32 -0000 1.2 +++ irix5-nat.c 25 Mar 2005 05:46:56 -0000 @@ -157,6 +157,7 @@ supply_fpregset (fpregset_t *fpregsetp) { int regi; static char zerobuf[32] = {0}; + char fsrbuf[64]; /* FIXME, this is wrong for the N32 ABI which has 64 bit FP regs. */ @@ -164,9 +165,17 @@ supply_fpregset (fpregset_t *fpregsetp) regcache_raw_supply (current_regcache, FP0_REGNUM + regi, (char *) &fpregsetp->fp_r.fp_regs[regi]); + /* We can't supply the FSR register directly to the regcache, + because there is a size issue: On one hand, fpregsetp->fp_csr + is 32bits long, while the regcache expects a 64bits long value. + So we use a buffer of the correct size and copy into it the register + value at the proper location. */ + memset (fsrbuf, 0, 4); + memcpy (fsrbuf + 4, &fpregsetp->fp_csr, 4); + regcache_raw_supply (current_regcache, mips_regnum (current_gdbarch)->fp_control_status, - (char *) &fpregsetp->fp_csr); + fsrbuf); /* FIXME: how can we supply FCRIR? SGI doesn't tell us. */ regcache_raw_supply (current_regcache, @@ -194,7 +203,20 @@ fill_fpregset (fpregset_t *fpregsetp, in if ((regno == -1) || (regno == mips_regnum (current_gdbarch)->fp_control_status)) - fpregsetp->fp_csr = *(unsigned *) &deprecated_registers[DEPRECATED_REGISTER_BYTE (mips_regnum (current_gdbarch)->fp_control_status)]; + { + char fsrbuf[64]; + + /* We can't fill the FSR register directly from the regcache, + because there is a size issue: On one hand, fpregsetp->fp_csr + is 32bits long, while the regcache expects a 64bits long buffer. + So we use a buffer of the correct size and copy the register + value from that buffer. */ + regcache_raw_read (current_regcache, + mips_regnum (current_gdbarch)->fp_control_status, + fsrbuf); + + memcpy (&fpregsetp->fp_csr, fsrbuf + 4, 4); + } }