Re: [rfa] Add SYMBOL_SET_LINKAGE_NAME

[Elena Zannoni <ezannoni@redhat.com>]

Daniel Jacobowitz writes:
 > 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.
 > 

Did you identify specific bottlenecks?

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

I don't speak for Andrew. I think he replied anyway.

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

I had to pry this info out of you over a few e-mail exchanges. Your
first posting didn't explain what you were doing, just that you were
testing some new approach. Since the patch seemed to be put together
in a hurry (and that's why I asked you to split it) I honestly wanted
to know what you were planning to do, especially since you are adding
a new macro. So it seemed to me that you were doing exactly that: going
ahead with the first stages of a big change but that the change itself
hadn't been discussed.

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

thank you.  What do you mean by separate? Where would you store the
demangled name? Have it demangled on demand only?