[1/5] Remove struct main_type.vptr_{fieldno,basetype}: finish TYPE_SPECIFIC_FIELD kind handling
Commit Message
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
> 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.
@@ -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;
}