Fix Irix core dumps

Fix Irix core dumps

[jkingdon]

Reading a core dump on Irix has bit-rotted some time since GDB 4.18
(which works).  The culprit has to do with the size of the floating
point registers (which thus affects all the registers after them in
the registers array).  The enclosed fix does enable GDB to read Irix
core dumps and doesn't look too hideous to me.  But I'd welcome
suggestions if there is a better way.

I also had to make a straightforward fix to bfd/irix-core.c; I'll be
sending that one to the binutils list.

2001-02-09  Jim Kingdon  <jkingdon@engr.sgi.com>

	* mips-tdep.c (mips_register_raw_size): If FP_REGISTER_DOUBLE,
	then floating point registers are 8 bytes.

Index: mips-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/mips-tdep.c,v
retrieving revision 1.40
diff -u -r1.40 mips-tdep.c
--- mips-tdep.c	2001/02/08 06:03:53	1.40
+++ mips-tdep.c	2001/02/09 22:59:43
@@ -420,7 +420,15 @@
   if (mips64_transfers_32bit_regs_p)
     return REGISTER_VIRTUAL_SIZE (reg_nr);
   else
-    return MIPS_REGSIZE;
+    {
+      /* For MIPS_ABI_N32 (for example) we need 8 byte floating point
+         registers.  */
+      if (reg_nr >= FP0_REGNUM && reg_nr < FP0_REGNUM+32
+	  && FP_REGISTER_DOUBLE)
+	return 8;
+
+      return MIPS_REGSIZE;
+    }
 }
 
 int

Re: Fix Irix core dumps

[Andrew Cagney]

jkingdon@engr.sgi.com wrote:
> 
> Reading a core dump on Irix has bit-rotted some time since GDB 4.18
> (which works).  The culprit has to do with the size of the floating
> point registers (which thus affects all the registers after them in
> the registers array).  The enclosed fix does enable GDB to read Irix
> core dumps and doesn't look too hideous to me.  But I'd welcome
> suggestions if there is a better way.
> 
> I also had to make a straightforward fix to bfd/irix-core.c; I'll be
> sending that one to the binutils list.
> 
> 2001-02-09  Jim Kingdon  <jkingdon@engr.sgi.com>
> 
>         * mips-tdep.c (mips_register_raw_size): If FP_REGISTER_DOUBLE,
>         then floating point registers are 8 bytes.

I'm checking this in (indented slightly different) (just got to wait for
a build).
I'm pretty sure it will affect GDBs ability to communicate with some
obscure remote target (what register_raw_size() returns changed :-/)
however, as it was it was certainly wrong.

Thanks!
	Andrew

PS: Have I ever mentioned my desire to completly separate remote.c from
register_raw_size() and instead have something outside of GDB specifying
what a packet looks like? :-)


> Index: mips-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/mips-tdep.c,v
> retrieving revision 1.40
> diff -u -r1.40 mips-tdep.c
> --- mips-tdep.c 2001/02/08 06:03:53     1.40
> +++ mips-tdep.c 2001/02/09 22:59:43
> @@ -420,7 +420,15 @@
>    if (mips64_transfers_32bit_regs_p)
>      return REGISTER_VIRTUAL_SIZE (reg_nr);
>    else
> -    return MIPS_REGSIZE;
> +    {
> +      /* For MIPS_ABI_N32 (for example) we need 8 byte floating point
> +         registers.  */
> +      if (reg_nr >= FP0_REGNUM && reg_nr < FP0_REGNUM+32
> +         && FP_REGISTER_DOUBLE)
> +       return 8;
> +
> +      return MIPS_REGSIZE;
> +    }
>  }
> 
>  int

Re: Fix Irix core dumps

[Jim Kingdon]

Andrew Cagney wrote:
> > Reading a core dump on Irix has bit-rotted 
> 
> I'm checking this in (indented slightly different)

Great!  Nick also checked in my BFD patch - 
http://sources.redhat.com/ml/binutils/2001-02/msg00454.html in case
anyone cares - so I was able to do a cvs update, rebuild, and things
work.  

> I'm pretty sure it will affect GDBs ability to communicate with some
> obscure remote target (what register_raw_size() returns changed :-/)

Yes, well as you point out hacking on register_raw_size to change the
behavior of remote.c is a kludge and should go away.  Whether to send
float registers, for example, or what size to send the registers as,
isn't really even a target-arch thing as such.  Seems like it should
be negotiated or self-describing in the protocol itself (maybe with
user-settable options if needed).