[Bug gdb/17764] Excessive seeking when reading debug data pegs the CPU @100%

["dje at google dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17764

--- Comment #4 from dje at google dot com ---
Huh.
46 megs of debug info is not that much (my monster benchmark has ~1.5G of debug
info, with a 350M .gdb_index section, and "gdb foo" takes 13 seconds to get to
the command prompt, 12 of which is spent reading the ELF symbol table, and 10
of that is spent demangling ELF symbols - which is to say ~1 second is spent on
debug info).
Without .gdb_index it takes about 55 seconds (this is from memory so I may be
off by a little, but not by much - I look at this issue a lot).

Plus gdb doesn't really "read" debug info in the .gdb_index case.
It's basically just an mmap() plus a bit of time spent processing the address
table.
So it's interesting that .gdb_index doesn't make a difference.

It would be interesting to see gprof data for gdb.

How easy would it to recompile gdb with '-O2 -pg',
write a small script to exercise the bug,
run gdb --batch -x the-script,
and then send us the output of "gprof gdb gmon.out"?
To recompile gdb, one could just cd into the gdb directory, rm *.o, and do
"make CFLAGS='-O2 -pg'".

Another idea, if it's taking a minute (so you've got time to do this), is to to
attach to the running gdb from a parent gdb, then do repeated "bt, continue,
ctrl-c", say every 5 seconds.  That's a quick hack way of collecting some data.

-- 
You are receiving this mail because:
You are on the CC list for the bug.