This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/5] Remove struct main_type.vptr_{fieldno,basetype}: finish TYPE_SPECIFIC_FIELD kind handling
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Doug Evans <xdje42 at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Sun, 1 Feb 2015 10:24:40 +0400
- Subject: Re: [PATCH 1/5] Remove struct main_type.vptr_{fieldno,basetype}: finish TYPE_SPECIFIC_FIELD kind handling
- Authentication-results: sourceware.org; auth=none
- References: <m3386yabg3 dot fsf at sspiff dot org>
> 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.
--
Joel