Re: [rfa] Add SYMBOL_SET_LINKAGE_NAME

[Daniel Jacobowitz <drow@false.org>]

On Tue, Feb 17, 2004 at 02:09:49PM -0500, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
>  > 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. 
> 
> >From your previous postings I understand is that your cplusplus stuff
> has a noticeable impact on performance and memory usage and you are
> trying to shave gdb's time and size wherever there is a chance. From
> Paul's postings instead I get the impression that he needs to revise
> the current interface.

This has, in fact, nothing to do with the C++ stuff.  This has to do
with the fact that when I start GDB on a 200MHz board with debug info
in glibc, it takes more than thirty seconds to load partial symbol
tables.  That's so slow as to be unusable.  It makes the entire
testsuite timeout, for one thing.

> You are saying that you are not willing to take a step back and look
> at things from a broader perspective.  I sincerely hope I
> misunderstood your statement.

You did.  Let me paste that quote with a little more context, OK?

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

Do you have an answer to my question?  Without one I don't understand
what Andrew is asking of me.

As for the interface, I don't think that the cleanup patches I've
posted so far have any substantial effect on the interface.  I was not
planning to post that existing grossness, my weekend hack, as a
proposal - it was an answer to "can you elaborate".  Before submitting
patches to implement it I would, I would hope, have asked for comments
on the interface.  But if I can't make the interface go faster, then
there's no point in proposing the interface.  That is a work in
progress.

You want a high level big picture?  I would like to separate the
concepts of full demangled name for language-specific use and
minimalist demangled data (basename, non-DMGL_PARAMS, whatever else)
needed for lookups in the symbol table.  This lets us reduce the
storage used by the symbol table, the data we have to generate at
startup, and the data we have to wade through when lookup things up in
the tables.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer