gdb performance is impossible!!
Anglister, Shlomo
shlomo.anglister@intel.com
Wed Sep 8 09:42:00 GMT 1999
Hi,
What we have is more and more people/companies/groups moving to C++.
Moreover, after so many years of SW development we all reached the
conclusion that shared libraries is the solution for large applications.
It seems that debugging large programs using many/large shared libraries is
a pain and a common problem to all architectures.
I think the real problem is that OS providers HP, SGI, SUN, IBM provide very
poor and basic documentation on how to debug large applications.
We found out that compiler switches + secret debug environment variables
could make the change !!!!!!
Anglister Shlomo
-----Original Message-----
From: Srikanth [ mailto:srikanth@cup.hp.com ]
< mailto:[mailto:srikanth@cup.hp.com ]>
Sent: Tuesday, September 07, 1999 7:17 PM
To: Guenther Grau
Cc: Jake Colman; gdb@sourceware.cygnus.com
< mailto:gdb@sourceware.cygnus.com >
Subject: Re: gdb performance is impossible!!
Guenther Grau wrote:
>
> Jake Colman wrote:
> > So, what should we be looking at as a potential problem?
The application is
> > rather large is linked with about 10 of our own shared
libraries - in
> > addition to whatever system libraries might be shared as
well. It uses g++
> > and is compiler with what think are the appropriate gcc
flags for shared
> > libraries and debugging.
> >
> > Any help would be greatly appreciated!
>
> How large is large? Our applications are large ~150 MB on
disk
> and it takes quite a while to read all the libs. (And yes,
our
> application is mainly c++ as well, so maybe this is a
problem?)
>
> Guenther
On the HP WDB, we have seen cases where ~50% of the
time is
spent in demangling the minimal symbols. The quick sort in
install_minimal_symbols() is also a big ticket item. It
would be
nice to defer sorting to just until it is needed and even
then
do it on a per objfile basis.
Srikanth.
More information about the Gdb
mailing list