From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20984 invoked by alias); 11 Apr 2009 10:20:18 -0000 Received: (qmail 20968 invoked by uid 22791); 11 Apr 2009 10:20:15 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44,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; Sat, 11 Apr 2009 10:20:09 +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 n3BAK7Qt001933 for ; Sat, 11 Apr 2009 06:20:07 -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 n3BAK9ki013921 for ; Sat, 11 Apr 2009 06:20:09 -0400 Received: from host0.dyn.jankratochvil.net (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n3BAK6HX011750 for ; Sat, 11 Apr 2009 06:20:07 -0400 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.3) with ESMTP id n3BAK4jP032662 for ; Sat, 11 Apr 2009 12:20:04 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.2/Submit) id n3BAK3pL032657 for gdb-patches@sourceware.org; Sat, 11 Apr 2009 12:20:03 +0200 Date: Sat, 11 Apr 2009 10:20:00 -0000 From: Jan Kratochvil To: gdb-patches@sourceware.org Subject: [patch] [0/5] Types reference counting (for VLA+Python) Message-ID: <20090411102003.GA32624@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes 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-04/txt/msg00199.txt.bz2 Hi, currently GDB knows only permanent types and objfile-associated types. GDB currently does not need more. The only special kind are types copied from closed objfiles for value history. As the value history is always kept in full length such types are in fact also permanent. The VLA (variable-length-arrays) patchset needs to create possibly a new type on each GDB stop (if inferior `variable[length]' will have different `length' on each GDB stop). The Python branch also dynamically creates new types used by GDB itself but possibly completely unreferenced and deallocatable later. To be true there exist some artificial temporary types such as in value_cast /* FIXME-type-allocation: need a way to free this type when we are done with it. */ , these can be freed by this implemented garbage collecting infrastructure. These are already leaking in current FSF GDB; fix based on this framework is currently not a part of this patchset. This is a work based on Tom Tromey's original one but it got changed a lot so blames to me first. The basic decisions of this patchset are about the differences between permant types (currently having TYPE_OBJFILE == NULL) and garbage collectable (=reclaimable) types: * Should the default allocation of types (alloc_type (NULL)) provide permanent type or a garbage collectable type? = Currently it creates a permanent type. It also means a fogotten GDB code part causes a type leak, not a crash. IMO there are more place where GDB allocates permanent types so the patchset is smaller this way. Tried the opposite first but got lost in the patches. * Should be the permanent<->reclaimable types differentiated by the TYPE_OBJFILE value itself or should both have NULL TYPE_OBJFILE and having some other differentiation factor? = Currently both have TYPE_OBJFILE (type) == NULL, one can find out if a type is reclaimable by: struct type_group_link link, *found; link.type = type; found = htab_find (type_group_link_table, &link); /* Not a permanent type? */ if (found) My former patchset was using: #define OBJFILE_INTERNAL ((struct objfile *) 1L) /* =permanent */ #define OBJFILE_MALLOC ((struct objfile *) 0L) /* =reclaimable */ But some GDB code finds out if a type is objfile-associated by a NULL comparison (no longer working for OBJFILE_MALLOC types). There also exist cross-type references (such as TYPE_TARGET_TYPE and many others). While one type may be no longer in use GDB one must not free it as it could create a stale reference in the other type. Therefore some inter-type references tracking is neeed. The Tom Tromey's patchset changed the alloc_type prototype to always require a parent (=related one) type to be specified: -alloc_type (struct objfile *objfile) +alloc_type (struct objfile *objfile, struct type *parent) But for example create_array_type needs two parents (target type and index type). Also one needs to be careful to never create a reference to a type without explicitely specifying the relation for memory management. As I had to write a types-crawling sanity checker to check for any such missing explicit references (by alloc_type's parent parameter) it got easier to already make types relationship runtime autodetected - and not just checked - but this function (now called type_group_link_check). Regression tested on x86_64-unknown-linux-gnu with FSF GDB and with the archer-jankratochvil-vla branch (http://sourceware.org/gdb/wiki/ArcherBranchManagement). Not tested with the Python branch (which will need to explicitely define the allocated types as reclaimable). Thanks, Jan