Re: [rfa] Add SYMBOL_SET_LINKAGE_NAME

Andrew Cagney
2004-02-17T23:10:26Z

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