From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25968 invoked by alias); 10 Aug 2003 19:03:10 -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 25959 invoked from network); 10 Aug 2003 19:03:08 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 10 Aug 2003 19:03:08 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p2/8.12.5) with ESMTP id h7AJ33bs002230; Sun, 10 Aug 2003 21:03:03 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p2/8.12.6) with ESMTP id h7AJ323g079945; Sun, 10 Aug 2003 21:03:02 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p2/8.12.6/Submit) id h7AJ32Bx079942; Sun, 10 Aug 2003 21:03:02 +0200 (CEST) Date: Sun, 10 Aug 2003 19:03:00 -0000 Message-Id: <200308101903.h7AJ32Bx079942@elgar.kettenis.dyndns.org> From: Mark Kettenis To: carlton@kealia.com CC: gdb-patches@sources.redhat.com In-reply-to: (message from David Carlton on Tue, 15 Jul 2003 09:48:31 -0700) Subject: Re: [RFC/RFA] Per-objfile data mechanism References: <200307131717.h6DHH425098569@elgar.kettenis.dyndns.org> <20030715161729.GA32437@nevyn.them.org> X-SW-Source: 2003-08/txt/msg00167.txt.bz2 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? Mark