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

[Tom Tromey <tromey@redhat.com>]

>>>>> "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.

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.

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.

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?

Tom