From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3247 invoked by alias); 26 Jun 2009 16:12:03 -0000 Received: (qmail 3238 invoked by uid 22791); 26 Jun 2009 16:12:02 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Jun 2009 16:11:56 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n5QGBqSp015672; Fri, 26 Jun 2009 12:11:53 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5QGBqge031231; Fri, 26 Jun 2009 12:11:52 -0400 Received: from opsy.redhat.com (vpn-225-10.phx2.redhat.com [10.3.225.10]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n5QGBpTu002841; Fri, 26 Jun 2009 12:11:51 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id F28DC508250; Fri, 26 Jun 2009 10:11:49 -0600 (MDT) To: "Ulrich Weigand" Cc: jan.kratochvil@redhat.com (Jan Kratochvil), gdb-patches@sourceware.org Subject: Re: [patch] [3/5] Types reference counting [make_function_type-objfile] References: <20090501144440.GA3213@host0.dyn.jankratochvil.net> <200906261323.n5QDN0Xi000973@d12av02.megacenter.de.ibm.com> From: Tom Tromey Reply-To: tromey@redhat.com Date: Fri, 26 Jun 2009 16:12:00 -0000 In-Reply-To: <200906261323.n5QDN0Xi000973@d12av02.megacenter.de.ibm.com> (Ulrich Weigand's message of "Fri\, 26 Jun 2009 15\:23\:00 +0200 \(CEST\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00730.txt.bz2 >>>>> "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. 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