From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24997 invoked by alias); 13 Aug 2003 20:54:21 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 24986 invoked from network); 13 Aug 2003 20:54:20 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 13 Aug 2003 20:54:20 -0000 Received: from drow by nevyn.them.org with local (Exim 4.20 #1 (Debian)) id 19n2dQ-0005Qq-1d for ; Wed, 13 Aug 2003 16:54:20 -0400 Date: Wed, 13 Aug 2003 20:54:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] Per-objfile data mechanism Message-ID: <20030813205420.GA20823@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <200307131717.h6DHH425098569@elgar.kettenis.dyndns.org> <20030715161729.GA32437@nevyn.them.org> <200308101903.h7AJ32Bx079942@elgar.kettenis.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200308101903.h7AJ32Bx079942@elgar.kettenis.dyndns.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-08/txt/msg00224.txt.bz2 On Sun, Aug 10, 2003 at 09:03:02PM +0200, Mark Kettenis wrote: > From: David Carlton > Date: Tue, 15 Jul 2003 09:48:31 -0700 > > On Tue, 15 Jul 2003 12:17:29 -0400, Daniel Jacobowitz > said: > > > The concept is nice, but I share David's concern. > > I was also going to write, based on a cursory misreading of Mark's > patch, that it simplified memory management in some circumstances, but > now that I look at it more closely, I think I just misread the patch. > (I may still be misreading the patch; my head is spinning with other > things.) Would it be possible/beneficial to modify the mechanism to > provide an optional per-datum cleanup function as well? > > I quite deliberately left per-datum initializers and destructors out > to encourage the use of the per-objfile obstacks. But they can always > be added if they're needed. > > So what's the final verdict. Should my patch go in, or do people have > concrete ideas about necessary improvements or alternative > implementations? As far as I'm concerned, it should go in. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer