From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4914 invoked by alias); 17 Aug 2011 13:44:33 -0000 Received: (qmail 4905 invoked by uid 22791); 17 Aug 2011 13:44:33 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-yi0-f41.google.com (HELO mail-yi0-f41.google.com) (209.85.218.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 17 Aug 2011 13:44:17 +0000 Received: by yib2 with SMTP id 2so814861yib.0 for ; Wed, 17 Aug 2011 06:44:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.116.67 with SMTP id f43mr3374687yhh.262.1313588656180; Wed, 17 Aug 2011 06:44:16 -0700 (PDT) Received: by 10.236.34.193 with HTTP; Wed, 17 Aug 2011 06:44:16 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Aug 2011 13:44:00 -0000 Message-ID: Subject: Re: [patch] PR python/10807 API for macros. From: Matt Rice To: pmuldoon@redhat.com Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: 2011-08/txt/msg00342.txt.bz2 On Wed, Aug 17, 2011 at 4:09 AM, Phil Muldoon wrote: > Matt Rice writes: > > >>> What do you mean by inconsistent memory management? =A0Can you expand/e= xplain >>> this. =A0Do macro definitions have a life-cycle in GDB? >> >> depends on the source of the macro, xmalloc directly for user-defined, >> or the macro table's obstack. >> >> from macroscope.c: >> /* A table of user-defined macros. =A0Unlike the macro tables used for >> =A0 =A0symtabs, this one uses xmalloc for all its allocation, not an >> =A0 =A0obstack, and it doesn't bcache anything; it just xmallocs things.= =A0So >> =A0 =A0it's perfectly possible to remove things from this, or redefine >> =A0 =A0things. =A0*/ >> >> I'm second guessing myself that caching the macro_source file is safe th= ough. > > Is there life-cycle management for macros? =A0(See py-symbol.c for > life-cycle management of symbols). =A0If so, we should invalidate (but ke= ep > around) the macro Python object, but run a validity routine to check > that the macro exists. Yeah, there is. I was confused by free_macro_table !=3D a destructor. it seems to be there to discard macro_tables in the case of 'early retireme= nt' they can *poof* via obstack regardless of free_macro_table. I'll just get rid of this for now, and do a deep copy of the macro on initialization, and see how that works with the macro iterator mechanism we discussed. revisit it later when i can figure out how to get at the obstack, and get it working correctly with the obstackless macro tables, we can change this under the hood without changing the API... I suppose i should add an is_valid method that just returns True for now with the deep copy. > If not, then I am not sure. =A0If you cache the macro_source file, do you > keep it around forever? =A0I am also unsure if it is ok to do this. just as long as the macro_object *, so potentially forever.