From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14439 invoked by alias); 26 Jun 2009 13:23:31 -0000 Received: (qmail 14430 invoked by uid 22791); 26 Jun 2009 13:23:30 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.29.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Jun 2009 13:23:16 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.14.3/8.13.8) with ESMTP id n5QDN2N9079364 for ; Fri, 26 Jun 2009 13:23:02 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 n5QDN2bl3489888 for ; Fri, 26 Jun 2009 15:23:02 +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 n5QDN15f000993 for ; Fri, 26 Jun 2009 15:23:02 +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 n5QDN0Xi000973; Fri, 26 Jun 2009 15:23:00 +0200 Message-Id: <200906261323.n5QDN0Xi000973@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 26 Jun 2009 15:23:00 +0200 Subject: Re: [patch] [3/5] Types reference counting [make_function_type-objfile] To: jan.kratochvil@redhat.com (Jan Kratochvil) Date: Fri, 26 Jun 2009 13:23:00 -0000 From: "Ulrich Weigand" Cc: tromey@redhat.com (Tom Tromey), gdb-patches@sourceware.org In-Reply-To: <20090501144440.GA3213@host0.dyn.jankratochvil.net> from "Jan Kratochvil" at May 01, 2009 04:44:40 PM 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/msg00706.txt.bz2 Jan Kratochvil wrote: > While jv-lang.c is also the case I originally found read_subroutine_type for > function returning void - where such DW_TAG_subprogram has no DW_AT_type > (return type) - and thus `builtin_type (gdbarch)->builtin_void' gets passed as > TYPE to make_function_type originally deriving the OBJFILE for its returned > function type from OBJFILE of that TYPE (internal in the void case). Sorry for not commenting earlier -- I had overlooked this change before, but ran into it now during my per-type architecture work. It seems to me the two issues you mention above are actually bugs: - I think the symbol readers should always return per-objfile types. This just makes everything simpler, in particular allocation of derived types (as you notice). I think it would also good to be able to guarantee that TYPE_OBJFILE of every symbol type is non-NULL ... - The Java generated types should *not* go onto the "fake" dynamics objfile in the first place. That objfile is somewhat bogus in that it isn't associated with an architecture (thus breaking my per-type architecture effort), and it also don't help with type lifetime issues as the fake objfile never goes away. I think those types should be allocated with a NULL objfile (in the future are per-gdbarch types) instead. > This patch fixes only the real-OBJFILE vs. NULL-OBJFILE part which fixes the > leak even without the types reference counting / garbage collecting patch. > > Whether NULL OBJFILE means permanent or discardable type I consider out of its > scope. You still can make it discardable by `type_init_group (function_type)'. The patch introduces one more instance of an interface where objfile may be NULL or non-NULL with different semantics; I'm trying to get rid of those. Also, I think the implementation is broken in the "type smashing" case: if there is an incoming type allocated in objfile A, but the argument to make_function_type specifies objfile B, the type gets "smashed" and reused, and its TYPE_OBJFILE gets redirected to objfile B even though the type still resides within objfile A's obstack ... struct type * make_function_type (struct type *type, struct type **typeptr, struct objfile *objfile) { struct type *ntype; /* New type */ if (typeptr == 0 || *typeptr == 0) /* We'll need to allocate one. */ { ntype = alloc_type (objfile); if (typeptr) *typeptr = ntype; } else /* We have storage, but need to reset it. */ { ntype = *typeptr; smash_type (ntype); TYPE_OBJFILE (ntype) = objfile; <--- here } Therefore, I'd prefer to fix the two problems mentioned above, and then revert your patch. (I'll be posting patches as a follow-up.) This should still solve the leak you originally experienced. Would this be OK with you? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com