This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: TYPE_NAME memory management

On Fri, Sep 4, 2009 at 3:41 PM, Tom Tromey<> wrote:
>>>>>> "Doug" == Doug Evans <> 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 *);


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]