From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5420 invoked by alias); 26 Jun 2009 17:06:39 -0000 Received: (qmail 5370 invoked by uid 22791); 26 Jun 2009 17:06:38 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Jun 2009 17:06:29 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.14.3/8.13.8) with ESMTP id n5QH6Rbl077304 for ; Fri, 26 Jun 2009 17:06:27 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5QH6Rkh3551346 for ; Fri, 26 Jun 2009 19:06:27 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n5QH6Q6K018186 for ; Fri, 26 Jun 2009 19:06:26 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id n5QH6PhE018173; Fri, 26 Jun 2009 19:06:25 +0200 Message-Id: <200906261706.n5QH6PhE018173@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 26 Jun 2009 19:06:25 +0200 Subject: Re: [patch] [3/5] Types reference counting [make_function_type-objfile] To: tromey@redhat.com Date: Fri, 26 Jun 2009 17:06:00 -0000 From: "Ulrich Weigand" Cc: jan.kratochvil@redhat.com (Jan Kratochvil), gdb-patches@sourceware.org In-Reply-To: from "Tom Tromey" at Jun 26, 2009 10:11:49 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00744.txt.bz2 Tom Tromey wrote: > >>>>> "Ulrich" == Ulrich Weigand 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