This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa] Add SYMBOL_SET_LINKAGE_NAME
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?