Re: [RFC/RFA] Per-objfile data mechanism

[Andrew Cagney <ac131313@redhat.com>]

> 
> 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