This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb eats 100% cpu for relative long time when I single step one instruction
On Tue, Jun 28, 2005 at 02:26:59PM +0200, Thomas Glanzmann wrote:
> Hello,
> I compiled gdb with profiling and did my workload:
>
> Each sample counts as 0.01 seconds.
> % cumulative self self total
> time seconds seconds calls s/call s/call name
> 64.71 127.12 127.12 2169997 0.00 0.00 lookup_minimal_symbol_by_pc_section
> 2.42 131.88 4.76 print_insn
> 1.95 135.71 3.83 723364 0.00 0.00 find_pc_sect_psymtab
> 1.72 139.09 3.39 723354 0.00 0.00 find_pc_sect_symtab
> 1.68 142.40 3.31 6052249 0.00 0.00 tui_file_adjust_strbuf
> 1.28 144.92 2.52 2170204 0.00 0.00 find_pc_sect_section
> 1.08 147.03 2.12 6052860 0.00 0.00 tui_file_fputs
> 1.04 149.07 2.04 21819200 0.00 0.00 xmalloc
>
> and this is the backtrace:
>
> (gdb) bt
> #0 0x080f12f2 in find_pc_sect_psymtab ()
> #1 0x080f2597 in find_pc_sect_symtab ()
> #2 0x080f0545 in blockvector_for_pc_sect ()
> #3 0x080f0624 in block_for_pc_sect ()
> #4 0x080ce0e1 in find_pc_sect_function ()
> #5 0x080ee196 in build_address_symbolic ()
> #6 0x080ee028 in print_address_symbolic ()
> #7 0x080ee3b3 in print_address ()
> #8 0x080bfe66 in tui_disassemble ()
> #9 0x080bffe7 in tui_find_disassembly_address ()
> #10 0x080c04be in tui_get_low_disassembly_address ()
Jason sent me a hint offlist and this confirms it. Because GDB can't
find a symbol, it's going all the way back to the nearest symbol it CAN
find, and disassembling forwards until it reaches this spot. It's
disassembling an awful lot of lines. This is specific to the TUI.
It could be made less completely dog-slow by using a different function
when searching, since print_address is what's really hurting you. It'd
still be pretty inefficient, but getting this right on x86 is tricky.
Take a look at tui_find_disassembly_address.
--
Daniel Jacobowitz
CodeSourcery, LLC