From: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
To: gdb@sources.redhat.com
Subject: Re: gdb eats 100% cpu for relative long time when I single step one instruction
Date: Tue, 28 Jun 2005 12:27:00 -0000 [thread overview]
Message-ID: <20050628122659.GK9291@cip.informatik.uni-erlangen.de> (raw)
In-Reply-To: <20050627221140.GH8659@cip.informatik.uni-erlangen.de>
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 ()
#11 0x080c553a in tui_show_frame_info ()
#12 0x080c157f in tui_selected_frame_level_changed_hook ()
#13 0x0808abed in select_frame ()
#14 0x08103fd2 in normal_stop ()
#15 0x08101b3b in proceed ()
#16 0x080ff125 in step_1 ()
#17 0x080fef27 in nexti_command ()
#18 0x080b3812 in do_cfunc ()
#19 0x080b5709 in cmd_func ()
#20 0x08083ec5 in execute_command ()
#21 0x0810eb5b in command_handler ()
#22 0x0810f1c6 in command_line_handler ()
#23 0x082021e0 in rl_callback_read_char () at callback.c:123
#24 0x0810e420 in rl_callback_read_char_wrapper ()
#25 0x0810ea18 in stdin_event_handler ()
#26 0x0810dd60 in handle_file_event ()
#27 0x0810d7e7 in process_event ()
#28 0x0810d838 in gdb_do_one_event ()
#29 0x08083b41 in do_catch_errors ()
#30 0x08083936 in catcher ()
#31 0x08083b9c in catch_errors ()
#32 0x080c190e in tui_command_loop ()
#33 0x0810b6bc in current_interp_command_loop ()
#34 0x0807b44c in captured_command_loop ()
#35 0x08083b41 in do_catch_errors ()
#36 0x08083936 in catcher ()
#37 0x08083b9c in catch_errors ()
#38 0x0807c1ec in captured_main ()
#39 0x08083b41 in do_catch_errors ()
#40 0x08083936 in catcher ()
#41 0x08083b9c in catch_errors ()
#42 0x0807c224 in gdb_main ()
#43 0x0807b437 in main ()
Greetings,
Thomas
next prev parent reply other threads:[~2005-06-28 12:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-27 21:27 Thomas Glanzmann
2005-06-27 21:48 ` Daniel Jacobowitz
2005-06-27 21:59 ` Thomas Glanzmann
2005-06-27 22:02 ` Daniel Jacobowitz
2005-06-27 22:11 ` Thomas Glanzmann
2005-06-28 12:27 ` Thomas Glanzmann [this message]
2005-06-28 13:13 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050628122659.GK9291@cip.informatik.uni-erlangen.de \
--to=sithglan@stud.uni-erlangen.de \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox