diff mbox

[1/5] Remove struct main_type.vptr_{fieldno,basetype}: finish TYPE_SPECIFIC_FIELD kind handling

Message ID m3386yabg3.fsf@sspiff.org
State New
Headers show

Commit Message

Doug Evans Jan. 25, 2015, 7:48 p.m. UTC
Hi.

The handling of TYPE_SPECIFIC_FIELD in copy_type_recursive, while maybe
correct, leaves one wondering.  So I've added handling of the remaining
possibilities.

Joel, I tried to create a testcase to exercise the handling of
TYPE_SPECIFIC_GNAT_STUFF but couldn't.  The issue is having a value
in the value history get preserved when the objfile gets unloaded,
and then trying to use that value: If we don't properly preserve
type_specific.gnat_stuff what happens?  I looked at the code and it
seems safe to just reinit the field with INIT_GNAT_SPECIFIC,
but another pair of eyes would help.

2015-01-24  Doug Evans  <xdje42@gmail.com>

	* gdbtypes.c (copy_type_recursive): Handle all TYPE_SPECIFIC_FIELD
	kinds.

Comments

Joel Brobecker Feb. 1, 2015, 6:24 a.m. UTC | #1
> The handling of TYPE_SPECIFIC_FIELD in copy_type_recursive, while maybe
> correct, leaves one wondering.  So I've added handling of the remaining
> possibilities.
> 
> Joel, I tried to create a testcase to exercise the handling of
> TYPE_SPECIFIC_GNAT_STUFF but couldn't.  The issue is having a value
> in the value history get preserved when the objfile gets unloaded,
> and then trying to use that value: If we don't properly preserve
> type_specific.gnat_stuff what happens?  I looked at the code and it
> seems safe to just reinit the field with INIT_GNAT_SPECIFIC,
> but another pair of eyes would help.
> 
> 2015-01-24  Doug Evans  <xdje42@gmail.com>
> 
> 	* gdbtypes.c (copy_type_recursive): Handle all TYPE_SPECIFIC_FIELD
> 	kinds.

I hadn't had time so far to to look into this.

I'm not sure whether the change is correct or not, yet: What it
is doing is creating a new type where the link to the parallel type
is now broken. I think that, prior to this change, it was only
semi broken, in the sense that if the type-specific discriminant
wasn't set to TYPE_SPECIFIC_GNAT_STUFF (what we used to do before,
I think), then parallel-type searches would perform a global lookup
by name.  With this change, we're setting the GNAT_STUFF in such
a way that it tells the parallel-lookup machinery that there is no
parallel type. So I think there might be a latent bug somewhere.

I'll keep an eye on this, and fix if needed.
diff mbox

Patch

diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
index 6d3c084..f528cb7 100644
--- a/gdb/gdbtypes.c
+++ b/gdb/gdbtypes.c
@@ -4185,18 +4185,35 @@  copy_type_recursive (struct objfile *objfile,
       copy_type_recursive (objfile,
 			   TYPE_VPTR_BASETYPE (type),
 			   copied_types);
+
   /* Maybe copy the type_specific bits.
 
      NOTE drow/2005-12-09: We do not copy the C++-specific bits like
      base classes and methods.  There's no fundamental reason why we
      can't, but at the moment it is not needed.  */
 
-  if (TYPE_CODE (type) == TYPE_CODE_FLT)
-    TYPE_FLOATFORMAT (new_type) = TYPE_FLOATFORMAT (type);
-  else if (TYPE_CODE (type) == TYPE_CODE_STRUCT
-	   || TYPE_CODE (type) == TYPE_CODE_UNION
-	   || TYPE_CODE (type) == TYPE_CODE_NAMESPACE)
-    INIT_CPLUS_SPECIFIC (new_type);
+  switch (TYPE_SPECIFIC_FIELD (type))
+    {
+    case TYPE_SPECIFIC_NONE:
+      break;
+    case TYPE_SPECIFIC_FUNC:
+      INIT_FUNC_SPECIFIC (new_type);
+      TYPE_CALLING_CONVENTION (new_type) = TYPE_CALLING_CONVENTION (type);
+      TYPE_NO_RETURN (new_type) = TYPE_NO_RETURN (type);
+      TYPE_TAIL_CALL_LIST (new_type) = NULL;
+      break;
+    case TYPE_SPECIFIC_FLOATFORMAT:
+      TYPE_FLOATFORMAT (new_type) = TYPE_FLOATFORMAT (type);
+      break;
+    case TYPE_SPECIFIC_CPLUS_STUFF:
+      INIT_CPLUS_SPECIFIC (new_type);
+      break;
+    case TYPE_SPECIFIC_GNAT_STUFF:
+      INIT_GNAT_SPECIFIC (new_type);
+      break;
+    default:
+      gdb_assert_not_reached ("bad type_specific_kind");
+    }
 
   return new_type;
 }