This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: TYPE_NAME memory management
- From: Tom Tromey <tromey at redhat dot com>
- To: Doug Evans <dje at google dot com>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, gdb at sourceware dot org
- Date: Fri, 04 Sep 2009 16:41:50 -0600
- Subject: Re: TYPE_NAME memory management
- References: <e394668d0909041417x3e65c584v7633e188bbdf4d6e@mail.gmail.com>
- Reply-to: tromey at redhat dot com
>>>>> "Doug" == Doug Evans <dje@google.com> writes:
Doug> Memory management for TYPE_NAME and TYPE_TAG_NAME is a bit random.
Doug> Sometimes it's a string constant, sometimes it's in malloc space,
Doug> sometimes it's on objfile's obstack, and now sometimes it can live in
Doug> mmap'd space.
Doug> Obviously one would rather not place ordering constraints on objfile
Doug> data cleanups. All the above uses are "ok" (modulo any memory leaks
Doug> from malloc'd strings) except for the new mmap'd values, so it seems
Doug> like the thing to do for now is copy such strings onto the objfile's
Doug> obstack.
Doug> I'm not sure what the speed loss will be, but I think it's the thing
Doug> to do pending data that says something more clever is needed.
My understanding is that in the past the rule was that if a type had an
objfile, then the type name could come directly from the debuginfo
(allocated on the objfile's obstack), because GDB made a guarantee about
the relative lifetimes of these objects. In particular, types were
copied by preserve_one_value at a point where the string data was still
live.
Why can't we maintain that guarantee for mmap'd debuginfo as well?
I realize that having a lot of lifetime dependencies can be tricky.
But, this one is fairly well established already.
For objfile-less types, I suspect we ought to always malloc any
associated strings. That will let us avoid memory leaks once the type
GC work is completed. (Currently I don't think we ever free such
types.)
Tom