This is the mail archive of the gdb@sourceware.org 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


> Sometimes it's a string constant, sometimes it's in malloc space,
> sometimes it's on objfile's obstack, and now sometimes it can live in
> mmap'd space.

My understanding was that, if the type belongs to an objfile, then
the type name should be allocated on the objfile obstack. I know we
have types that do not belong to objfiles (types that are duplicated
from objfile types in order to preserve a value from the value history,
or gdbarch types; any others?), and these types are allocated on the
heap, including the type name, but I don't think we ever deallocate
these types.

Perhaps we might want to review all TYPE_NAME and TYPE_TAG_NAME
assignments. If there is a memory leak due to an incorrect malloc,
we might want to fix that too.

> [...] except for the new mmap'd values, so it seems like the thing to
> do for now is copy such strings onto the objfile's obstack.

This sounds right.

> I'm not sure what the speed loss will be, but I think it's the thing
> to do pending data that says something more clever is needed.

Agreed - correctness before speed :)

-- 
Joel


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