From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2875 invoked by alias); 15 Jul 2003 17:27:48 -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 2868 invoked from network); 15 Jul 2003 17:27:47 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 15 Jul 2003 17:27:47 -0000 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19cTaa-0000WR-00 for ; Tue, 15 Jul 2003 13:27:44 -0400 Date: Tue, 15 Jul 2003 17:27:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] Per-objfile data mechanism Message-ID: <20030715172744.GA1940@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <200307131717.h6DHH425098569@elgar.kettenis.dyndns.org> <20030715161729.GA32437@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-07/txt/msg00294.txt.bz2 On Tue, Jul 15, 2003 at 09:48:31AM -0700, David Carlton wrote: > On Tue, 15 Jul 2003 12:17:29 -0400, Daniel Jacobowitz said: > > > The concept is nice, but I share David's concern. > > I'm not sure what my concern is; I'm just curious. :-) I guess my > inchoate attitude (as an interested observer who has a patch waiting > for approval that adds per-objfile data) is that I don't mind at all > adding new data to every objfile: there just aren't enough of them to > worry about. The advantage of doing that as a member is that its > existence is right there in objfiles.h for anybody to look at. The > advantage of Mark's mechanism is that, if the data is only used by > one file, then you don't have to clutter objfiles.h with it. > > 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? Sure. And that's the best reason I've heard so far for doing it this way. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer