This is the mail archive of the gdb-patches@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: [RFA 01/22] Change selttest.c to use use std::vector


>>>>> "Trevor" == Trevor Saunders <tbsaunde@tbsaunde.org> writes:

Tom> That would be nice; though we could probably use std::set and std::map
Tom> in gdb as well.  One wrinkle with hash tables is that they're sometimes
Tom> allocated on obstacks; would gcc's handle this?

Trevor> No, they don't support that at the moment, though I suppose it
Trevor> would be fine for keys or values to point into obstacks.  Is
Trevor> there a good reason for this other than using obstacks to
Trevor> provide a sort of automatic memory management?

Sometimes it's just to avoid more work -- cleaning up an obstack is
easy.  E.g., see dwarf2loc.c:func_verify_no_selftailcall Uses like this
can easily be replaced.

There are also spots that allocate a hash table on the objfile obstack.
Now, this is a bit unfortunate because it means that hash table resizes
will create a kind of "leak" -- not a true leak (the memory is tracked
and will be freed), but basically some chunk of memory will no longer be
useful.

It's possible to address these cases in other ways, though more
difficult.

Tom


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