* Re: gdb/regcache.c:211: undefined reference to `GET_SAVED_REGISTER'
[not found] <u8k8dof7ah.fsf@gromit.rhein-neckar.de>
@ 2000-08-11 11:09 ` Andrew Cagney
2000-08-11 11:23 ` Mark Kettenis
1 sibling, 0 replies; 2+ messages in thread
From: Andrew Cagney @ 2000-08-11 11:09 UTC (permalink / raw)
To: Andreas Jaeger; +Cc: gdb
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
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: gdb/regcache.c:211: undefined reference to `GET_SAVED_REGISTER'
[not found] <u8k8dof7ah.fsf@gromit.rhein-neckar.de>
2000-08-11 11:09 ` gdb/regcache.c:211: undefined reference to `GET_SAVED_REGISTER' Andrew Cagney
@ 2000-08-11 11:23 ` Mark Kettenis
1 sibling, 0 replies; 2+ messages in thread
From: Mark Kettenis @ 2000-08-11 11:23 UTC (permalink / raw)
To: aj, ac131313.cygnus.com; +Cc: gdb
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
^ permalink raw reply [flat|nested] 2+ messages in thread