* stabsread.c (cleanup_undefined_types): Use replace_type, not memcpy.

(read_type): Doc fix.
* gdbtypes.c (replace_type): Doc fix.
This commit is contained in:
Jim Blandy 2002-05-04 00:21:09 +00:00
parent 2ae1c2d222
commit 13a393b0d3
3 changed files with 27 additions and 9 deletions

View File

@ -1,5 +1,9 @@
2002-05-03 Jim Blandy <jimb@redhat.com> 2002-05-03 Jim Blandy <jimb@redhat.com>
* stabsread.c (cleanup_undefined_types): Use replace_type, not memcpy.
(read_type): Doc fix.
* gdbtypes.c (replace_type): Doc fix.
* stabsread.c (multiply_defined_struct): New complaint. * stabsread.c (multiply_defined_struct): New complaint.
(read_struct_type): If the type we were passed isn't empty, or (read_struct_type): If the type we were passed isn't empty, or
incomplete, don't read the new struct type into it; complain, incomplete, don't read the new struct type into it; complain,

View File

@ -521,10 +521,10 @@ finish_cv_type (struct type *type)
/* Replace the contents of ntype with the type *type. /* Replace the contents of ntype with the type *type.
This function should not be necessary, but is due to quirks in the stabs When building recursive types, it is necessary to update a type's
reader. This should go away. It does not handle the replacement type definition after people already have references to it. The C
being cv-qualified; it could be easily fixed to, but it should go away, language's concept of an `incomplete type' is an acknowledgement of
remember? */ this. */
void void
replace_type (struct type *ntype, struct type *type) replace_type (struct type *ntype, struct type *type)
{ {

View File

@ -2537,7 +2537,24 @@ again:
the related problems with unnecessarily stubbed types; the related problems with unnecessarily stubbed types;
someone motivated should attempt to clean up the issue someone motivated should attempt to clean up the issue
here as well. Once a type pointed to has been created it here as well. Once a type pointed to has been created it
should not be modified. */ should not be modified.
Well, it's not *absolutely* wrong. Constructing recursive
types (trees, linked lists) necessarily entails modifying
types after creating them. Constructing any loop structure
entails side effects. The Dwarf 2 reader does handle this
more gracefully (it never constructs more than once
instance of a type object, so it doesn't have to copy type
objects wholesale), but it still mutates type objects after
other folks have references to them.
Keep in mind that this circularity/mutation issue shows up
at the source language level, too: C's "incomplete types",
for example. So the proper cleanup, I think, would be to
limit GDB's type smashing to match exactly those required
by the source language. So GDB could have a
"complete_this_type" function, but never create unnecessary
copies of a type otherwise. */
replace_type (type, xtype); replace_type (type, xtype);
TYPE_NAME (type) = NULL; TYPE_NAME (type) = NULL;
TYPE_TAG_NAME (type) = NULL; TYPE_TAG_NAME (type) = NULL;
@ -5122,10 +5139,7 @@ cleanup_undefined_types (void)
&& (TYPE_CODE (SYMBOL_TYPE (sym)) == && (TYPE_CODE (SYMBOL_TYPE (sym)) ==
TYPE_CODE (*type)) TYPE_CODE (*type))
&& STREQ (SYMBOL_NAME (sym), typename)) && STREQ (SYMBOL_NAME (sym), typename))
{ replace_type (*type, SYMBOL_TYPE (sym));
memcpy (*type, SYMBOL_TYPE (sym),
sizeof (struct type));
}
} }
} }
} }