On Thu, May 24, 2012 at 2:28 PM, Doug Evans wrote: > On Thu, May 24, 2012 at 10:58 AM, Doug Evans wrote: >> Hi. >> >> I'm not entirely sure this patch is correct, but it feels correct (*1), >> and is a massive win. >> "info var Task" in one large program goes from 350 seconds to 28 seconds. >> >> [...] >> >> 2012-05-23  Doug Evans   >> >>        * symtab.c (lookup_msymbol_in_objfile): New function. >>        (search_symbols): Call it. > > Hmmm. > One thing that occurs to me is separate debug objfiles. > lookup_msymbol_in_objfile should probably search them. This is a revised patch. It scans separate debug files. I think I understand the code better so I've removed the FIXME: The comments in the code were misleading, find_pc_symtab is, I think, an optimization to avoid unnecessarily calling lookup_symbol. This patch also adds a (nfiles == 0) check to the second minsym loop: there's no point in scanning minsyms for specific files. The output is different from the previous code, I didn't take into account the symbols that gdb creates for @plt entries. I think if we want to continue to provide the current output, we should add an option to "info var|fun|type" to produce it: the normal case shouldn't be that slow. This patch removes the gdb-created minsyms from the output. Another way to go is to print them. I don't have a strong opinion on either choice. [The different with the current behaviour is that if the minsym is found in any objfile then the current code won't print it in the "Non-debugging symbols" section of the output.] Ok to check in? 2012-05-25 Doug Evans * symtab.c (minimal_symbol): New member created_by_gdb. * elfread.c (elf_symtab_read): Set created_by_gdb for @plt minsym created by gdb. * symtab.c (lookup_msymbol_in_objfile): New function. (search_symbols): Call it. Only scan minsyms if nfiles == 0.