Re: A gdb+bfd string pool?

[Andrew Cagney <cagney@gnu.org>]

> Personally, I'd be against this unless we have reason to believe that
>> it's an important optimization.  I don't like global data in general,
>> even if it's only global to one component of a program, and having
>> that data shared by both GDB and BFD makes me even more nervous.
>> (Singleton is not my favorite design pattern.)  So it sets of warning
>> bells for general design reasons; our lack of const-correctness when
>> dealing with names makes me even more nervous.
> 
> 
> I have the exact same feeling.
> 
> May I recommend that, should we decide to use one, we isolate it from
> GDB's code via a layer. So each module would use it's layer as if it was
> not shared. It will make the move back easier, in case it's ever needed.

Ok, ok, I've been sufficiently beaten to a pulp :-)

I've also come across a reason that a single pool may not be such a good 
idea.  GDB had (it broke >4 years ago and is now beyond repair) a 
technique for caching per-object data on a memory-mapped disk.  Having 
the objfile symbol table point into a shared pool would make any future 
plans to re-implement that technique unworkable.

enjoy,
Andrew