From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: brobecker@adacore.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC/mips] Problem with fetching/setting 32 bit registers
Date: Fri, 25 Mar 2005 12:26:00 -0000 [thread overview]
Message-ID: <200503251226.j2PCQZMf031903@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <20050325054917.GC32590@adacore.com> (message from Joel Brobecker on Thu, 24 Mar 2005 21:49:17 -0800)
Date: Thu, 24 Mar 2005 21:49:17 -0800
From: Joel Brobecker <brobecker@adacore.com>
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?
Looks better but:
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];
Looks like you're confused about bits and bytes. Guess 8 is large
enough here ;-).
/* FIXME, this is wrong for the N32 ABI which has 64 bit FP regs. */
Could you remove the redundant parenthesis here while you're at it:
@@ -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);
+ }
}
next prev parent reply other threads:[~2005-03-25 12:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-24 4:14 Joel Brobecker
2005-03-24 4:26 ` Daniel Jacobowitz
2005-03-25 5:49 ` Joel Brobecker
2005-03-25 12:26 ` Mark Kettenis [this message]
2005-03-26 0:39 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200503251226.j2PCQZMf031903@elgar.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox