From: Mark Kettenis <kettenis@wins.uva.nl>
To: aj@suse.de, ac131313.cygnus.com@delius.kettenis.local
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb/regcache.c:211: undefined reference to `GET_SAVED_REGISTER'
Date: Fri, 11 Aug 2000 11:23:00 -0000 [thread overview]
Message-ID: <200008111809.e7BI9xq09451@delius.kettenis.local> (raw)
In-Reply-To: <u8k8dof7ah.fsf@gromit.rhein-neckar.de>
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
prev parent reply other threads:[~2000-08-11 11:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <u8k8dof7ah.fsf@gromit.rhein-neckar.de>
2000-08-11 11:09 ` Andrew Cagney
2000-08-11 11:23 ` Mark Kettenis [this message]
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=200008111809.e7BI9xq09451@delius.kettenis.local \
--to=kettenis@wins.uva.nl \
--cc=ac131313.cygnus.com@delius.kettenis.local \
--cc=aj@suse.de \
--cc=gdb@sourceware.cygnus.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