From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15277 invoked by alias); 9 Sep 2009 16:40:59 -0000 Received: (qmail 15121 invoked by uid 22791); 9 Sep 2009 16:40:56 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Sep 2009 16:40:45 +0000 Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id n89Gegn3017880 for ; Wed, 9 Sep 2009 17:40:42 +0100 Received: from yxe28 (yxe28.prod.google.com [10.190.2.28]) by zps18.corp.google.com with ESMTP id n89Ge7wC027309 for ; Wed, 9 Sep 2009 09:40:40 -0700 Received: by yxe28 with SMTP id 28so5396852yxe.19 for ; Wed, 09 Sep 2009 09:40:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.103.4 with SMTP id a4mr821786ybc.217.1252514439590; Wed, 09 Sep 2009 09:40:39 -0700 (PDT) In-Reply-To: References: Date: Wed, 09 Sep 2009 16:40:00 -0000 Message-ID: Subject: Re: TYPE_NAME memory management From: Doug Evans To: tromey@redhat.com Cc: Paul Pluzhnikov , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00142.txt.bz2 On Fri, Sep 4, 2009 at 3:41 PM, Tom Tromey wrote: >>>>>> "Doug" =3D=3D Doug Evans writes: > > Doug> Memory management for TYPE_NAME and TYPE_TAG_NAME is a bit random. > > Doug> Sometimes it's a string constant, sometimes it's in malloc space, > Doug> sometimes it's on objfile's obstack, and now sometimes it can live = in > Doug> mmap'd space. > > Doug> Obviously one would rather not place ordering constraints on objfile > Doug> data cleanups. =A0All the above uses are "ok" (modulo any memory le= aks > Doug> from malloc'd strings) except for the new mmap'd values, so it seems > Doug> like the thing to do for now is copy such strings onto the objfile's > Doug> obstack. > Doug> I'm not sure what the speed loss will be, but I think it's the thing > Doug> to do pending data that says something more clever is needed. > > My understanding is that in the past the rule was that if a type had an > objfile, then the type name could come directly from the debuginfo > (allocated on the objfile's obstack), because GDB made a guarantee about > the relative lifetimes of these objects. =A0In particular, types were > copied by preserve_one_value at a point where the string data was still > live. > > Why can't we maintain that guarantee for mmap'd debuginfo as well? > > I realize that having a lot of lifetime dependencies can be tricky. > But, this one is fairly well established already. > > For objfile-less types, I suspect we ought to always malloc any > associated strings. =A0That will let us avoid memory leaks once the type > GC work is completed. =A0(Currently I don't think we ever free such > types.) In an effort to move this along, how about if we partition the objfile_data cleanups into two steps. Given that we don't want to require an ordering on the objfile_data cleanups, and (to phrase it one way) we need to allow different modules' cleanups to refer to other module's "objfile_data", and given my lack of skill in picking good names, suppose we call the first step "save" and we call the second step "free". i.e. in objfiles.c change struct objfile_data { unsigned index; void (*cleanup) (struct objfile *, void *); }; to struct objfile_data { unsigned index; /* The objfile is about to be freed. Save anything needed from it. */ void (*save) (struct objfile *, void *); /* Free all objfile-related resources held. */ void (*free) (struct objfile *, void *); }; It would require adding a parameter to register_objfile_data_with_cleanup and updating all the callers. ?