Re: [RFA] patch for 2384, dangling TYPE_VPTR_BASETYPE

["Doug Evans" <dje at google dot com>]

On Dec 13, 2007 4:29 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Thu, Dec 13, 2007 at 04:10:55PM -0800, Doug Evans wrote:
> > Ok to check in?  Or any suggestions for what's needed instead?
>
> Your patch seems strange to me.  Do we need the new fieldno /
> basetype, or not?  If we don't, we shouldn't be calculating it at all;
> if we do, there should be something detectable which breaks when you
> do this.  It's not just a cache, since the interface doesn't offer any
> other way to return the new fieldno / basetype besides in-place
> modification.

For the test case in the patch, type info for the derived class is left
as opaque/stub, and when the vptr is needed check_typedef is called
which notices the fact that is has an incomplete type and does a lookup
by name to get the complete typo info.  In this case check_typedef
notices it has a cross-objfile reference and returns a pointer to the
complete type info without updating the original type. This way cross-objfile
pointers don't get created and the required data is still obtained when needed.

There are other use cases.  If base and derived are both in the
same compilation unit then dwarf2read.c will fill in
TYPE_VPTR_{BASETYPE,FIELDNO} (and presumably stabsread.c
but I don't know offhand), and fill_in_vptr_fieldno is a nop.

Another use case is if base and derived are in different compilation
units but in the same objfile.  Here dwarf2read.c will leave the base
class as a stub for derived's type info.  Later when vptr is needed
fill_in_vptr_fieldno is called and it will notice fieldno < 0 and call
check_typedef on the base type.  check_typedef will see that
orig_type and newtype are in the same objfile and will call
make_cv_type to update the original type with the complete
type info.

> I happen to know that for GNU v3 - which is in practice the only thing
> that any GDB users use nowadays - we don't need these fields any more.
> We still use them, but we could do without, since the ABI is quite
> clear on where to find the vtable pointer.
>
> For GNU v2, which is theoretically still supported, we do need this
> information.

Clearly fill_in_vptr_fieldno can't create cross-objfile pointers.
All callers of fill_in_vptr_fieldno (should) expect that it may fail.

I'm not quite sure what you're suggesting, as it relates to the patch.
The v3 abi still needs logic to handle cross-objfile references,
though it could be done without the use of fill_in_vptr_fieldno.