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

["Ulrich Weigand" <uweigand@de.ibm.com>]

Tom Tromey wrote:
> >>>>> "Ulrich" == Ulrich Weigand <uweigand@de.ibm.com> writes:
> 
> Ulrich> - I think the symbol readers should always return per-objfile
> Ulrich> types.  This just makes everything simpler, in particular
> Ulrich> allocation of derived types (as you notice).  I think it would
> Ulrich> also good to be able to guarantee that TYPE_OBJFILE of every
> Ulrich> symbol type is non-NULL ...
> 
> My recollection is that we have a few places where an objfile-attached
> type can be derived from a NULL-objfile type.  Index types at least,
> but ISTR also something from Ada.

Well, for temporary GDB-created index types we typically have
  index_type:  NULL objfile  (usually builtin_type_int32 today)
  range_type:  inherits NULL objfile from index_type
  array_type:  inherits NULL objfile from range_type

Ada sometimes creates "temporary" objfile-attached types, but those
always are based on other objfile-attached types.  (These probably
should really not be objfile-attached in the first place, in particular
once we have type garbage collection in place.)

> I'm fine with changing this and adding an invariant like "a type with
> an objfile may only reference other types from the same objfile".  I
> think I must have just assumed that this would be too hard.

Yes, this is the invariant I'd like to impose.

> Ulrich> - The Java generated types should *not* go onto the "fake"
> Ulrich> dynamics objfile in the first place.  That objfile is somewhat
> Ulrich> bogus in that it isn't associated with an architecture (thus
> Ulrich> breaking my per-type architecture effort), and it also don't
> Ulrich> help with type lifetime issues as the fake objfile never goes
> Ulrich> away.  I think those types should be allocated with a NULL
> Ulrich> objfile (in the future are per-gdbarch types) instead.
> 
> This phony objfile is also not multi-inferior-safe.
> 
> It seems to me that this java stuff is like a rough prototype of how
> better debugging for JITs might work -- make a dynamic objfile based
> on information from the running inferior.  So, I suppose it would be
> nice to fix it up rather than nuke it :)
> 
> For the lifetime issue, it seems like this objfile should be treated
> however a .so objfile is treated.

Well, yes, but we know when an .so is removed.  How should we know when
the "JIT objfile" can be removed?

> Ulrich> Also, I think the implementation is broken in the "type
> Ulrich> smashing" case: if there is an incoming type allocated in
> Ulrich> objfile A, but the argument to make_function_type specifies
> Ulrich> objfile B, the type gets "smashed" and reused, and its
> Ulrich> TYPE_OBJFILE gets redirected to objfile B even though the type
> Ulrich> still resides within objfile A's obstack ...
> 
> Is this really valid?  It seems to me that it ought to be an internal
> error.  Otherwise aren't we at risk for memory corruption, if objfile
> A goes away?

Yes, this would be invalid usage in any case.  I'd be fine with
adding an internal error.

Bye,
Ulrich

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