[rfa] Add SYMBOL_SET_LINKAGE_NAME

[Andrew Cagney]

>   > Er, why not start by defining a relevant interface and then work  
>   > inwards?  That way potential clients, such as paulh, can determine if it 
>   > is sufficient for their needs.  The first implementation doesn't even 
>   > need to be fast, just correct.  Once we've hard data on the interfaces 
>   > run-time behavioral characteristics we can consider symtab internal
>   > changes.
> 
>   Because the cleaner interface is not my goal - it's a side goal to my
>   actual aims, which are improved GDB startup time and memory usage.  An
>   implementation which is not fast is a step backwards.  I don't
>   understand how you can propose to measure "hard data" on "run-time
>   behavioral characteristics" without implementing the symtab internal
>   changes - what am I missing?

I was refering to the interface, not the implementation.  For instance:

- how often it is called?
- when it is called?
- with what parameters it is called?
- how time critical are the calls?

And of course, how many existing interfaces can, as a consequence, be 
deprecated, obsoleted or deleted.  The implementation is secondary.  As 
PaulH noted, the initial implementation could even be based on the 
existing structure (just stripping off trailing parameter list).

Elena wrote:

> The symbol table is already a mess, with multiple redundant
> interfaces.  At the moment there isn't a clear picture of what various
> bits of gdb need from the symbol table.  How do we know the direction
> we are going is improving things generally across the board?  How can
> we know that, if this is not the case, the impact is not too heavy on
> other parts and we can live with the tradeoff?

In the -file-list-exec-source-files discussion, notice that I'm trying 
to emphasize that things need to be a step removed from the symbol table 
- define the requirements according to the users needs, and not 
according to the existing symtab implementation.

Andrew