Re: Removal of demangled names from partial symbols

[Daniel Berlin <dberlin at redhat dot com>]

"Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de> writes:

> > symbols, most  concentrated in one object file (the main program in this 
> > case, which  has 100 meg of debug info, and 100k symbols) ,we have chains 
> 
> Are you really meaning that 100 MB of debug info are generated from one
> .o file ?
> 
Not only am I really meaning it, it's not uncommon.
Because with the STL and whatnot, you end up with a lot of code in
headers, and with template instantiations, where you get debug info
for every instantiation, even if the duplicate *code* is factored out
by linkonce sections, you have lots of debug info in C++ apps.
The two main issues with this type of thing are memory usage, and
lookup speed.

I'm working on both, the memory usage, and the speed of the symbol
lookup.
As it stands, it takes >200 meg of memory (easily) to debug this 100
meg app.

100 meg of this comes from the way we just read the entire .debug_info
section in in one huge block of memory we allocate, rather than doing
something smart, like mmap. I have patches that use BFD's file_window
stuff (which uses mmap), that i've been meaning to submit. Saves us a
bunch of memory, and the memory it does use is now shared, rather than
just ours. 

This is also why i spent time working up ways to remove duplicate info
and whatnot.

The mozilla folks (fer instance) are desperate to be able to actually
debug GDB on a workstation that has less than 4 gig of memory. And
they should be able to.

Currently, the symbol lookup isn't just slow in these situations, when
we try to debug large apps  with "only" double the memory that the app's debug
info takes up, we  hit the swap very hard, and it's completely
unusuable.  We get no  relief, because it has to touch literally every
symbol until it finds the symbol, so we end up having to swap out
just about everything, and then swap it back in when we find the
symbol, damning us to have to swap it back out again when we go
looking for another symbol.

If you have an app as large on disk as you have memory, you are
literally guaranteed to get worst case swapping behavior on every symbol
lookup.

If we were binary searches, we'd touch log (100k), or 16, symbols max,
to find one in all of them. In reality, since we are doing it block by
block, the number is a bit higher, but not much.
That means we touch such a ridicuously lower amount of swap, it's not
funny.

It's like 1 or 2 pages per block of symbols versus all the pages for
the symbols in that block.




> In that case I am beginning to understand why you need to get rid of the
> linear search so desperately...
> 

Yup.
gdb is worthless on medium->large size C++ apps right now.
literally worthless.

--Dan