Re: TYPE_NAME memory management

[Doug Evans <dje@google.com>]

On Fri, Sep 4, 2009 at 3:41 PM, Tom Tromey<tromey@redhat.com> wrote:
>>>>>> "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.)

In an effort to move this along, how about if we partition the
objfile_data cleanups into two steps.  Given that we don't want to
require an ordering on the objfile_data cleanups, and (to phrase it
one way) we need to allow different modules' cleanups to refer to
other module's "objfile_data", and given my lack of skill in picking
good names, suppose we call the first step "save" and we call the
second step "free".

i.e. in objfiles.c change

struct objfile_data
{
  unsigned index;
  void (*cleanup) (struct objfile *, void *);
};

to

struct objfile_data
{
  unsigned index;
  /* The objfile is about to be freed.  Save anything needed from it.  */
  void (*save) (struct objfile *, void *);
  /* Free all objfile-related resources held.  */
  void (*free) (struct objfile *, void *);
};

It would require adding a parameter to
register_objfile_data_with_cleanup and updating all the callers.

?