This is the mail archive of the
mailing list for the GDB project.
Re: [patch] PR python/10807 API for macros.
On Wed, Aug 17, 2011 at 4:09 AM, Phil Muldoon <email@example.com> wrote:
> Matt Rice <firstname.lastname@example.org> writes:
>>> What do you mean by inconsistent memory management? ?Can you expand/explain
>>> this. ?Do 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 though.
> 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.
Yeah, there is.
I was confused by free_macro_table != a destructor.
it seems to be there to discard macro_tables in the case of 'early retirement'
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
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. ?If you cache the macro_source file, do you
> keep it around forever? ?I am also unsure if it is ok to do this.
just as long as the macro_object *, so potentially forever.