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: [rfa] Add SYMBOL_SET_LINKAGE_NAME


> 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



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