From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: "Peter.Schauer" Cc: gdb-patches@sources.redhat.com, gdb@sources.redhat.com Subject: Re: Removal of demangled names from partial symbols Date: Wed, 06 Dec 2000 17:32:00 -0000 Message-id: References: <200012050836.JAA29089@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-12/msg00037.html "Peter.Schauer" 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