Re: TYPE_NAME memory management

[Tom Tromey <tromey@redhat.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