MIPS targets broken by dummy frame/regcache changes

MIPS targets broken by dummy frame/regcache changes

[Daniel Jacobowitz]

I get this backtrace on MIPS/Linux:
#0  error (string=0x7591c4 "Unknowable register number %d.")
    at /opt/src/gdb/src-gdblinks/gdb/utils.c:628
#1  0x004f7fc8 in register_addr (regno=72, blockend=0)
    at /opt/src/gdb/src-gdblinks/gdb/mips-linux-tdep.c:254
#2  0x00575658 in store_register (regno=72) at /opt/src/gdb/src-gdblinks/gdb/infptrace.c:440
#3  0x005757e0 in store_inferior_registers (regno=72) at /opt/src/gdb/src-gdblinks/gdb/infptrace.c:470
#4  0x004666f4 in legacy_write_register_gen (regnum=72, myaddr=0x1067cff8)
    at /opt/src/gdb/src-gdblinks/gdb/regcache.c:838
#5  0x00466cdc in write_register_gen (regnum=0, buf=0x0)
    at /opt/src/gdb/src-gdblinks/gdb/regcache.c:903
#6  0x00466f4c in write_register_bytes (myregstart=0, myaddr=0x1067ced8 "", inlen=0)
    at /opt/src/gdb/src-gdblinks/gdb/regcache.c:950
#7  0x004646e8 in regcache_cpy (dst=0x1006afc0, src=0x1022c5f8)
    at /opt/src/gdb/src-gdblinks/gdb/regcache.c:350

The problem is that you're copying the whole regcache blindly.  But there's
holes in it that we can't store.  I'm sure you remember register 72 - it
used to be the frame pointer; now it's a hole in the register cache.  We get
to it and try to write it, even though it doesn't exist.

I get the same thing for the next couple registers, up to 89.  For now I've
turned it down to a warning in my local tree...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: MIPS targets broken by dummy frame/regcache changes

[Daniel Jacobowitz]

On Thu, Oct 10, 2002 at 04:51:12PM -0400, Daniel Jacobowitz wrote:
> I get this backtrace on MIPS/Linux:
> #0  error (string=0x7591c4 "Unknowable register number %d.")
>     at /opt/src/gdb/src-gdblinks/gdb/utils.c:628
> #1  0x004f7fc8 in register_addr (regno=72, blockend=0)
>     at /opt/src/gdb/src-gdblinks/gdb/mips-linux-tdep.c:254
> #2  0x00575658 in store_register (regno=72) at /opt/src/gdb/src-gdblinks/gdb/infptrace.c:440
> #3  0x005757e0 in store_inferior_registers (regno=72) at /opt/src/gdb/src-gdblinks/gdb/infptrace.c:470
> #4  0x004666f4 in legacy_write_register_gen (regnum=72, myaddr=0x1067cff8)
>     at /opt/src/gdb/src-gdblinks/gdb/regcache.c:838
> #5  0x00466cdc in write_register_gen (regnum=0, buf=0x0)
>     at /opt/src/gdb/src-gdblinks/gdb/regcache.c:903
> #6  0x00466f4c in write_register_bytes (myregstart=0, myaddr=0x1067ced8 "", inlen=0)
>     at /opt/src/gdb/src-gdblinks/gdb/regcache.c:950
> #7  0x004646e8 in regcache_cpy (dst=0x1006afc0, src=0x1022c5f8)
>     at /opt/src/gdb/src-gdblinks/gdb/regcache.c:350
> 
> The problem is that you're copying the whole regcache blindly.  But there's
> holes in it that we can't store.  I'm sure you remember register 72 - it
> used to be the frame pointer; now it's a hole in the register cache.  We get
> to it and try to write it, even though it doesn't exist.
> 
> I get the same thing for the next couple registers, up to 89.  For now I've
> turned it down to a warning in my local tree...

To follow up to myself, here's the hack I'm using to quiet this:

Index: regcache.c
===================================================================
RCS file: /cvs/src/src/gdb/regcache.c,v
retrieving revision 1.58
diff -u -p -r1.58 regcache.c
--- regcache.c	25 Aug 2002 23:44:30 -0000	1.58
+++ regcache.c	13 Oct 2002 23:09:27 -0000
@@ -947,7 +947,10 @@ write_register_bytes (int myregstart, ch
 
       /* Is this register completely within the range the user is writing?  */
       else if (myregstart <= regstart && regend <= myregend)
-	write_register_gen (regnum, myaddr + (regstart - myregstart));
+	{
+	  if (REGISTER_NAME (regnum)[0] != 0)
+	    write_register_gen (regnum, myaddr + (regstart - myregstart));
+	}
 
       /* The register partially overlaps the range being written.  */
       else

Andrew, does this look reasonable?  If so we should do it for read
also.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: MIPS targets broken by dummy frame/regcache changes

[Daniel Jacobowitz]

On Thu, Oct 10, 2002 at 04:51:12PM -0400, Daniel Jacobowitz wrote:
> I get this backtrace on MIPS/Linux:
> #0  error (string=0x7591c4 "Unknowable register number %d.")
>     at /opt/src/gdb/src-gdblinks/gdb/utils.c:628
> #1  0x004f7fc8 in register_addr (regno=72, blockend=0)
>     at /opt/src/gdb/src-gdblinks/gdb/mips-linux-tdep.c:254
> #2  0x00575658 in store_register (regno=72) at /opt/src/gdb/src-gdblinks/gdb/infptrace.c:440
> #3  0x005757e0 in store_inferior_registers (regno=72) at /opt/src/gdb/src-gdblinks/gdb/infptrace.c:470
> #4  0x004666f4 in legacy_write_register_gen (regnum=72, myaddr=0x1067cff8)
>     at /opt/src/gdb/src-gdblinks/gdb/regcache.c:838
> #5  0x00466cdc in write_register_gen (regnum=0, buf=0x0)
>     at /opt/src/gdb/src-gdblinks/gdb/regcache.c:903
> #6  0x00466f4c in write_register_bytes (myregstart=0, myaddr=0x1067ced8 "", inlen=0)
>     at /opt/src/gdb/src-gdblinks/gdb/regcache.c:950
> #7  0x004646e8 in regcache_cpy (dst=0x1006afc0, src=0x1022c5f8)
>     at /opt/src/gdb/src-gdblinks/gdb/regcache.c:350
> 
> The problem is that you're copying the whole regcache blindly.  But there's
> holes in it that we can't store.  I'm sure you remember register 72 - it
> used to be the frame pointer; now it's a hole in the register cache.  We get
> to it and try to write it, even though it doesn't exist.
> 
> I get the same thing for the next couple registers, up to 89.  For now I've
> turned it down to a warning in my local tree...

Found the real problem.  It's my own fault for approving carelessly...
Andrew, you checked in this to mips-linux-tdep.c:

@@ -28,9 +29,7 @@
 int
 mips_linux_cannot_fetch_register (int regno)
 {
-  if (regno >= FP_REGNUM)
-    return 1;
-  else if (regno == PS_REGNUM)
+  if (regno == PS_REGNUM)
     return 1;
   else if (regno == ZERO_REGNUM)
     return 1;
@@ -41,9 +40,7 @@ mips_linux_cannot_fetch_register (int re
 int
 mips_linux_cannot_store_register (int regno)
 {
-  if (regno >= FP_REGNUM)
-    return 1;
-  else if (regno == PS_REGNUM)
+  if (regno == PS_REGNUM)
     return 1;
   else if (regno == ZERO_REGNUM)
     return 1;

It's wrong.  First of all, you changed the behavior for registers above
FP_REGNUM, like UNUSED_REGNUM.  Secondly, FP_REGNUM did not become OK
to fetch/store after this patch.  Just the numbering changed.

I'll fix it in a little bit.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: MIPS targets broken by dummy frame/regcache changes

[Andrew Cagney]

> @@ -28,9 +29,7 @@
>  int
>  mips_linux_cannot_fetch_register (int regno)
>  {
> -  if (regno >= FP_REGNUM)
> -    return 1;
> -  else if (regno == PS_REGNUM)
> +  if (regno == PS_REGNUM)
>      return 1;
>    else if (regno == ZERO_REGNUM)
>      return 1;
> @@ -41,9 +40,7 @@ mips_linux_cannot_fetch_register (int re
>  int
>  mips_linux_cannot_store_register (int regno)
>  {
> -  if (regno >= FP_REGNUM)
> -    return 1;
> -  else if (regno == PS_REGNUM)
> +  if (regno == PS_REGNUM)
>      return 1;
>    else if (regno == ZERO_REGNUM)
>      return 1;
> 
> It's wrong.  First of all, you changed the behavior for registers above
> FP_REGNUM, like UNUSED_REGNUM.  Secondly, FP_REGNUM did not become OK
> to fetch/store after this patch.  Just the numbering changed.
> 
> I'll fix it in a little bit.

Ulgh, what was I thinking.

The reggroup code will let this be fixed properly - can finally specify 
exactly which registers should be saved/restored across an inferior 
function call.

Andrew

Re: MIPS targets broken by dummy frame/regcache changes

[Daniel Jacobowitz]

On Fri, Oct 18, 2002 at 07:41:50PM -0400, Andrew Cagney wrote:
> 
> >@@ -28,9 +29,7 @@
> > int
> > mips_linux_cannot_fetch_register (int regno)
> > {
> >-  if (regno >= FP_REGNUM)
> >-    return 1;
> >-  else if (regno == PS_REGNUM)
> >+  if (regno == PS_REGNUM)
> >     return 1;
> >   else if (regno == ZERO_REGNUM)
> >     return 1;
> >@@ -41,9 +40,7 @@ mips_linux_cannot_fetch_register (int re
> > int
> > mips_linux_cannot_store_register (int regno)
> > {
> >-  if (regno >= FP_REGNUM)
> >-    return 1;
> >-  else if (regno == PS_REGNUM)
> >+  if (regno == PS_REGNUM)
> >     return 1;
> >   else if (regno == ZERO_REGNUM)
> >     return 1;
> >
> >It's wrong.  First of all, you changed the behavior for registers above
> >FP_REGNUM, like UNUSED_REGNUM.  Secondly, FP_REGNUM did not become OK
> >to fetch/store after this patch.  Just the numbering changed.
> >
> >I'll fix it in a little bit.
> 
> Ulgh, what was I thinking.
> 
> The reggroup code will let this be fixed properly - can finally specify 
> exactly which registers should be saved/restored across an inferior 
> function call.

Looking forward to it!

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer