[patch] [3/5] Types reference counting [make_function_type-objfile]

Ulrich Weigand uweigand@de.ibm.com
Fri Jun 26 17:12:00 GMT 2009


Jan Kratochvil wrote:
> > Also, I think the implementation is broken in the "type smashing" case:
> > if there is an incoming type allocated in objfile A, but the argument to
> > make_function_type specifies objfile B,
> 
> I do not think it can happen.  So far always type A referencing -> type
> B either had the same TYPE_OBJFILE or TYPE_OBJFILE(B) was NULL.  Using such
> assertion-checks without facing problems.
> 
> As there cannot be a DWARF reference across objfiles (there can be one just
> across CUs) cross-file type references use TYPE_IS_OPAQUE and they get
> resolved each time on dereferencing such reference by calling check_typedef.

Yes, there is no current usage of the make_function_type interface that
does this, and it would indeed be broken.  I guess was I was trying to
say is that the new interface that allows to specify an objfile independently
of the target type may appear to invite such incorrect usage ...

But in either case, I agree this should be prevented by assertion checks.

> > Therefore, I'd prefer to fix the two problems mentioned above, and then
> > revert your patch.
> 
> If the current rule:
> # So far always type A referencing -> type B had either the same TYPE_OBJFILE
> # or TYPE_OBJFILE(B) was NULL.
> 
> will be changed to:
> # Type A referencing -> type B had the same TYPE_OBJFILE.

Mostly.  We still can have the case were TYPE_OBJFILE(A) is NULL but
TYPE_OBJFILE(B) is non-NULL, for example where A is a temporary array
and B the element type.

The way I see the invariant is
  If Type A references Type B *and* A is objfile-associated
  *then* B must be associated to the same objfile

> I only welcome it and sure I agree with reverting my patch afterwards.

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com



More information about the Gdb-patches mailing list