Re: gdb/regcache.c:211: undefined reference to `GET_SAVED_REGISTER'

Re: gdb/regcache.c:211: undefined reference to `GET_SAVED_REGISTER'

[Andrew Cagney]

Mine.  Will fix.

	Andrew
From kettenis@wins.uva.nl Fri Aug 11 11:10:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: aj@suse.de, ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb/regcache.c:211: undefined reference to `GET_SAVED_REGISTER'
Date: Fri, 11 Aug 2000 11:10:00 -0000
Message-id: <200008111810.e7BIAQS09455@delius.kettenis.local>
References: <u8k8dof7ah.fsf@gromit.rhein-neckar.de>
X-SW-Source: 2000-08/msg00058.html
Content-length: 1033

   From: Andreas Jaeger <aj@suse.de>
   Date: 11 Aug 2000 11:58:46 +0200

   By default (!GDB_MULTI_ARCH && !GET_SAVED_REGISTER) no replacement is
   defined.

Looks like Andrew accidentiliy removed the GET_SAVED_REGISTER stuff
from regcache.c (there's no ChangeLog for that bit).  The attached
patch restores it.  Andrew, I'll leave it to you to check it in and
put an appropriate notice in the ChangeLog :-).

Mark


Index: regcache.c
===================================================================
RCS file: /cvs/src/src/gdb/regcache.c,v
retrieving revision 1.7
diff -u -p -r1.7 regcache.c
--- regcache.c	2000/08/11 03:19:22	1.7
+++ regcache.c	2000/08/11 18:08:21
@@ -200,6 +200,11 @@ default_get_saved_register (char *raw_bu
     *addrp = addr;
 }
 
+#if !defined (GET_SAVED_REGISTER)
+#define GET_SAVED_REGISTER(raw_buffer, optimized, addrp, frame, regnum, lval) \
+  default_get_saved_register(raw_buffer, optimized, addrp, frame, regnum, lval)
+#endif
+
 void
 get_saved_register (char *raw_buffer,
 		    int *optimized,
From guo@cup.hp.com Fri Aug 11 11:11:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb linux testing regressions (compared to 7/24)
Date: Fri, 11 Aug 2000 11:11:00 -0000
Message-id: <Pine.LNX.4.10.10008111110050.807-100000@hpcll168.cup.hp.com>
References: <200008111804.e7BI4kx09433@delius.kettenis.local>
X-SW-Source: 2000-08/msg00059.html
Content-length: 267

>I probably should have asked for the Linux *kernel* version (uname
>-a).  If you're running Linux 2.0.x, the failures you're seeing would
>be pretty normal.

% uname -a
Linux hpcll168.cup.hp.com 2.2.5-15smp #1 SMP Mon Apr 19 22:43:28 EDT
1999 i686 unknown

- Jimmy

Re: gdb/regcache.c:211: undefined reference to `GET_SAVED_REGISTER'

[Mark Kettenis]

   From: Andreas Jaeger <aj@suse.de>
   Date: 11 Aug 2000 11:58:46 +0200

   By default (!GDB_MULTI_ARCH && !GET_SAVED_REGISTER) no replacement is
   defined.

Looks like Andrew accidentiliy removed the GET_SAVED_REGISTER stuff
from regcache.c (there's no ChangeLog for that bit).  The attached
patch restores it.  Andrew, I'll leave it to you to check it in and
put an appropriate notice in the ChangeLog :-).

Mark


Index: regcache.c
===================================================================
RCS file: /cvs/src/src/gdb/regcache.c,v
retrieving revision 1.7
diff -u -p -r1.7 regcache.c
--- regcache.c	2000/08/11 03:19:22	1.7
+++ regcache.c	2000/08/11 18:08:21
@@ -200,6 +200,11 @@ default_get_saved_register (char *raw_bu
     *addrp = addr;
 }
 
+#if !defined (GET_SAVED_REGISTER)
+#define GET_SAVED_REGISTER(raw_buffer, optimized, addrp, frame, regnum, lval) \
+  default_get_saved_register(raw_buffer, optimized, addrp, frame, regnum, lval)
+#endif
+
 void
 get_saved_register (char *raw_buffer,
 		    int *optimized,
From ac131313@cygnus.com Fri Aug 11 11:54:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>, aj@suse.de
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb/regcache.c:211: undefined reference to `GET_SAVED_REGISTER'
Date: Fri, 11 Aug 2000 11:54:00 -0000
Message-id: <39944B1F.941193F4@cygnus.com>
References: <u8k8dof7ah.fsf@gromit.rhein-neckar.de> <200008111809.e7BI9xq09451@delius.kettenis.local>
X-SW-Source: 2000-08/msg00061.html
Content-length: 587

Mark Kettenis wrote:
> 
>    From: Andreas Jaeger <aj@suse.de>
>    Date: 11 Aug 2000 11:58:46 +0200
> 
>    By default (!GDB_MULTI_ARCH && !GET_SAVED_REGISTER) no replacement is
>    defined.
> 
> Looks like Andrew accidentiliy removed the GET_SAVED_REGISTER stuff
> from regcache.c (there's no ChangeLog for that bit).  The attached
> patch restores it.  Andrew, I'll leave it to you to check it in and
> put an appropriate notice in the ChangeLog :-).

Yes.  Sorry.  That snuck through :-(.   It is part of another patch that
moves all of GET_SAVED_REGISTER to gdbarch.[hc].

	Andrew
From ac131313@cygnus.com Fri Aug 11 20:09:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Ingham <jingham@apple.com>
Cc: gdb@sources.redhat.com
Subject: Re: Changing the "enclosing_type" of a value structure
Date: Fri, 11 Aug 2000 20:09:00 -0000
Message-id: <3994BF2A.7B903D3F@cygnus.com>
References: <B5B5E410.3CCA%jingham@apple.com>
X-SW-Source: 2000-08/msg00062.html
Content-length: 405

Jim Ingham wrote:

>    /* If we have the full object, but for some reason the enclosing
>       type is wrong, set it *//* pai: FIXME -- sounds iffy */

I like the comment...

>        return (value_ptr) xrealloc (val, sizeof (struct type)
>                                     + TYPE_LENGTH (new_type));

Should it simply refuse to expand a type?  That extra data becomes
undefined in general?

	Andrew
From jingham@apple.com Mon Aug 14 11:32:00 2000
From: Jim Ingham <jingham@apple.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: <gdb@sources.redhat.com>
Subject: Re: Changing the "enclosing_type" of a value structure
Date: Mon, 14 Aug 2000 11:32:00 -0000
Message-id: <B5BD8935.40C8%jingham@apple.com>
References: <3994BF2A.7B903D3F@cygnus.com>
X-SW-Source: 2000-08/msg00063.html
Content-length: 2457

Also sprach Andrew Cagney:

> Jim Ingham wrote:
> 
>> /* If we have the full object, but for some reason the enclosing
>> type is wrong, set it *//* pai: FIXME -- sounds iffy */
> 
> I like the comment...

Yeah, this is the sort of thing that really warms your heart after you have
spent a couple of days chasing down memory corruption...

> 
>> return (value_ptr) xrealloc (val, sizeof (struct type)
>> + TYPE_LENGTH (new_type));
> 
> Should it simply refuse to expand a type?  That extra data becomes
> undefined in general?
> 


The sketch I sent in the last note was not right.  You have to change the
lazy flag - which will take care of your objection (though in all the code
paths I could see the data had not been read when this switch was done) -
and you have to stick the new value back into the value chain, or the old
value will get freed, which is BAD.  Here is another - better - version.
This one seems to work pretty well.

value_ptr
value_change_enclosing_type (value_ptr val, struct type *new_encl_type)
{

  /* If you follow the code, most of the time that this function
     is called, the types are the same...  So shortcut this case. */

  if (new_encl_type == VALUE_ENCLOSING_TYPE (val))
    {
      return val;
    }
  else if (TYPE_LENGTH (new_encl_type)
           > TYPE_LENGTH (VALUE_ENCLOSING_TYPE (val)))
    {
       value_ptr old_val = val;
       register value_ptr prev;

       val = (value_ptr) xrealloc (old_val, sizeof (struct value)
                                       + TYPE_LENGTH (new_encl_type));

       /* We have to make sure this ends up in the same place in the value
         chain as the original copy, so it's clean-up behavior is the same.
          If the value has been released, this is a waste of time, but there
          is no way to tell that in advance, so... */

       if (old_val != all_values)
         {
           for (prev = all_values; prev != NULL; prev = prev->next)
             {
               if (prev->next == old_val)
                 {
                   prev->next = val;
                   break;
                 }
             }
         }
    }

  VALUE_ENCLOSING_TYPE (val) = new_encl_type;

  /* If we had to change the enclosing type, the data in the value
     is no longer good.  Setting lazy back to 1 will force it to be
     reread. */

  VALUE_LAZY (val) = 1;

  return val;
}


Jim
-- 
Jim Ingham                                 jingham@apple.com
Apple Computer