This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
[GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores?
- From: Paul Smith <psmith at gnu dot org>
- To: gdb at sourceware dot org
- Date: Thu, 16 May 2013 15:42:15 -0400
- Subject: [GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores?
- Reply-to: psmith at gnu dot org
Hi all. Is anyone aware of an issue with a big slowdown running macros
on core files? I'm not sure if this is related to GCC 4.8 or GDB 7.6,
or what, but I'm seeing a 4x or more slowdown when running macros on
core files from previous releases.
Running against a live process is the same speed as before.
Details: we were building/debugging with the system compiler and
debugger (e.g., GCC 4.5.2 / GDB 7.2). Speed of macros when dealing with
core files here was acceptable. FYI, our code is C++ with a small to
moderate number of templates and compiled (in this case) with "-g", and
no optimization.
I wanted to use a new compiler with an encapsulated environment so we
could unify our build toolchain. I created a separately-installed
version of GCC 4.8.0/binutils 2.23.2.
Then we discovered that trying to use older GDB instances with the
results of this build failed, because they couldn't read the DWARF4
object format generated by GCC 4.8.0. I thought about dropping back to
an older DWARF format but instead I built GDB 7.6 and added that to our
toolchain.
Now we can debug and everything works well, except that we've noticed
this major slowdown only when debugging corefiles.
The macros are nothing fancy: they just walk through some of our data
structures printing interesting information; for example:
set $current = $arg0.first
set $size = 0
while $current
printf "node[%u]: id=", $size
if $current->flags & 1
printf "*"
end
if $current->flags & 2
printf "^"
end
printf "%d, localId=%d, incarnation=%d, type=%d, state=%d\n",
$current->node->nodeId, $current->node->localId,
$current->incarnationNumber, $current->node->nodeType,
$current->node->nodeState
set $current = $current.next
set $size++
end
Against a core file it takes a second or longer per iteration of this
loop! FWIW, the class this macro operates on is very large and contains
a lot of data per object.
Any ideas? Is there a handy way to tell where the slowdown is happening
here? Should we just drop back to DWARF2 or DWARF3 (I haven't checked
if that will help tho)?