* stabsread.c (cleanup_undefined_types): Use replace_type, not memcpy.
authorJim Blandy <jimb@codesourcery.com>
Sat, 4 May 2002 00:21:09 +0000 (00:21 +0000)
committerJim Blandy <jimb@codesourcery.com>
Sat, 4 May 2002 00:21:09 +0000 (00:21 +0000)
(read_type): Doc fix.
* gdbtypes.c (replace_type): Doc fix.

gdb/ChangeLog
gdb/gdbtypes.c
gdb/stabsread.c

index 4e8de26..d758201 100644 (file)
@@ -1,5 +1,9 @@
 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.
        (read_struct_type): If the type we were passed isn't empty, or
        incomplete, don't read the new struct type into it; complain,
index fa01f36..9132c40 100644 (file)
@@ -521,10 +521,10 @@ finish_cv_type (struct 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
-   reader.  This should go away.  It does not handle the replacement type
-   being cv-qualified; it could be easily fixed to, but it should go away,
-   remember?  */
+   When building recursive types, it is necessary to update a type's
+   definition after people already have references to it.  The C
+   language's concept of an `incomplete type' is an acknowledgement of
+   this.  */
 void
 replace_type (struct type *ntype, struct type *type)
 {
index 74a873e..7065b7b 100644 (file)
@@ -2537,7 +2537,24 @@ again:
               the related problems with unnecessarily stubbed types;
               someone motivated should attempt to clean up the issue
               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);
            TYPE_NAME (type) = NULL;
            TYPE_TAG_NAME (type) = NULL;
@@ -5122,10 +5139,7 @@ cleanup_undefined_types (void)
                            && (TYPE_CODE (SYMBOL_TYPE (sym)) ==
                                TYPE_CODE (*type))
                            && STREQ (SYMBOL_NAME (sym), typename))
-                         {
-                           memcpy (*type, SYMBOL_TYPE (sym),
-                                   sizeof (struct type));
-                         }
+                          replace_type (*type, SYMBOL_TYPE (sym));
                      }
                  }
              }