From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28627 invoked by alias); 17 Aug 2011 11:10:00 -0000 Received: (qmail 28618 invoked by uid 22791); 17 Aug 2011 11:09:59 -0000 X-SWARE-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 17 Aug 2011 11:09:43 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7HB9gri000470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Aug 2011 07:09:42 -0400 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p7HB9eDt032199; Wed, 17 Aug 2011 07:09:41 -0400 From: Phil Muldoon To: Matt Rice Cc: gdb-patches@sourceware.org Subject: Re: [patch] PR python/10807 API for macros. References: Reply-to: pmuldoon@redhat.com X-URL: http://www.redhat.com Date: Wed, 17 Aug 2011 11:10:00 -0000 In-Reply-To: (Matt Rice's message of "Tue, 16 Aug 2011 08:16:31 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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/msg00339.txt.bz2 Matt Rice writes: >> What do you mean by inconsistent memory management? =C2=A0Can you expand= /explain >> this. =C2=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. Unlike the macro tables used for > symtabs, this one uses xmalloc for all its allocation, not an > obstack, and it doesn't bcache anything; it just xmallocs things. So > it's perfectly possible to remove things from this, or redefine > things. */ > > I'm second guessing myself that caching the macro_source file is safe tho= ugh. Is there life-cycle management for macros? (See py-symbol.c for life-cycle management of symbols). If so, we should invalidate (but keep around) the macro Python object, but run a validity routine to check that the macro exists. If not, then I am not sure. If you cache the macro_source file, do you keep it around forever? I am also unsure if it is ok to do this. >> Same as above, re failure. =C2=A0Why do you need a custom hash function? > > needed the hash function for storing in sets > for the same reason that set([{"a" : "b"}]) doesn't work > Traceback (most recent call last): > File "", line 1, in > TypeError: unhashable type: 'dict' > > mostly I was just using it in the tests, > the only use case I can imagine is once we have a symtab_and_line > macros() function > you could use it to find the difference between 2 'macro scopes' That's totally fine, I just missed the usage in the testsuite. >> These comments are somewhat complex, and really follow the three paragra= ph >> comments belows. So take them as one big comment. >> ... >> Normally, a function that does not return a Python object has to >> deal with stack printing/error detection internally. Because this is not >> a Python function (IE returning NULL signifies an error, you have to >> check and deal with the error here) =C2=A0this is done with >> gdbpy_print_stack. =C2=A0However .... ... >> I'm really puzzled what to do here. =C2=A0I'm assuming the iterator won't >> stop because the helper function has encountered errors (at least, the >> function pointer prototype is a void return). =C2=A0Because macro_for_ea= ch is >> a GDB iterator function that calls (through a function pointer and other >> GCC helpers) add_macro_to_list, which itself calls Python functions, >> each iteration can raise a Python error. =C2=A0If we print and cope with= the >> error for each iteration in the helper as suggested above, the user will >> see each exception and no exception data is overwritten. =C2=A0Also there >> seems (to me, at least) no way to abort the iterator earlier. >> >> OTOH we want to make sure that this function returns correctly, >> according to how Python functions should. =C2=A0So we SHOULD return NULL= here >> if there were errors, but if we do what I suggested above, every >> exception will already be printed and cleared. =C2=A0So returning NULL h= ere >> will cause Python to complain. =C2=A0But I also don't want previous iter= ation >> exceptions overwritten either. Maybe your way is right in that we only >> report the last iterations exception. =C2=A0Or maybe we should construct= our >> own exception and return that. =C2=A0I do not know. =C2=A0I'd appreciate >> comments here from the maintainers. > > another approach may be to use a 'macro iterator' method which calls a > python function with the converted arguments. I initially had > macro_object just copy everything into a python object. but the > macros() implementations used far too much memory (in a hello world) > building a full list with each macro containing an include_trail, > with a macro iterator we wouldn't return a list, just call the > callback for each macro, it'd mean error handling would have to happen > in said python callback function, but we'd be free of any concerns > with caching the macro_source_file, otoh memory size probably won't go > away it just means we have punted said concerns to the user, if they > try to store it in a list, they'd probably run into the same thing. I think you and I are violently agreeing, but saying for effect anyway. You might also call the iterator and store them temporarily in a non-Python way (VEC, or something that suits your purpose). Then as a second-pass, convert them to the Python object, error-checking as appropriate? Cheers, Phil