This is the mail archive of the gdb-patches@sources.redhat.com 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: [RFC/RFA] Per-objfile data mechanism



The concrete reason for that suggestion is that I have a patch awaiting review adding some per-objfile data that consists of an expanding hash table; that can't be handled with an obstack. In general, I get the feeling that we're moving a bit more to data structures that are less obstack friendly, but who knows. Having said that:

So I'm not the only one looking at the N different structures mapping onto partial symbols :-) They appear to bloat the overhead of a partial symbol to the point where a more unified structure and a full symbol might be smaller!


I just converted gdbarch to an obstack and encountered two occasions where xmrealloc would have made my life a little easier. Instead of proposing the use of mmalloc (and hence xmrealloc) though, I modified the algorithms / structures a little and avoided the problem.

Is it possible that the same situtation is being encountered here? A growable hash table can be implemented without needing to reclaim memory - something more along the lines of a btree?

Andrew



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