This is the mail archive of the
mailing list for the GDB project.
Re: [patch] [3/5] Types reference counting [make_function_type-objfile]
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: tromey at redhat dot com
- Cc: jan dot kratochvil at redhat dot com (Jan Kratochvil), gdb-patches at sourceware dot org
- Date: Fri, 26 Jun 2009 19:06:25 +0200 (CEST)
- Subject: Re: [patch] [3/5] Types reference counting [make_function_type-objfile]
Tom Tromey wrote:
> >>>>> "Ulrich" == Ulrich Weigand <email@example.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.
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE