[GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores?

[Paul Smith <psmith@gnu.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)?