So my latest investigations suggest that the problem is the
"-file-list-exec-source-files" command which generates the huge output due
to the large number of files that is part of the project.

The following shows the problem from the command line.

echo -file-list-exec-source-files > /tmp/gdb.in
gdb MyExec < /tmp/gdb.in > /tmp/gdb.out
wc /tmp/gdb.out
     11      69 3725105 /tmp/gdb.out

(Note that this is on a my home box, where the output is much larger than
what I reported this morning possibly due to different paths).

So there are still several questions:

* Why does it take several minutes to parse a 3.7M file? Could it be
related to the fact that gdb-mi/emacs concatinates the entire string before
trying to parse it. Still 3.7M is far too much.

* Noted that I can't run gdb MyExec < /tmp/gdb.in in a shell buffer. It
gets slower and slower while the CPU stays at 100%.

* There is a huge redundancy in gdb.out. The command
-file-list-exec-source-files should output all source files included, but
the same source files are listed multiple times. Consider the huge file
size reduction after sorting and uniq'ing:

perl -ne 'while(/(\w+)=\"(.*?)\"/g) { print "$1=$2\n"; }' /tmp/gdb.out |
sort | uniq | wc

   3931    3931  220654

Why doesn't -file-list-exec-source file do uniq internally. This seems like
a bug in gdb.

* Why does gdb-mi.el do -file-list-exec-source-files at all? Can't it
search for source files on demand?

Regards,
Dov

On Tue, May 8, 2012 at 8:47 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Chong Yidong <cyd@gnu.org>
> > Date: Wed, 09 May 2012 00:25:00 +0800
> > Cc: 10580@debbugs.gnu.org
> >
> > Those are status messages from turning on GDB's MI (machine interface)
> > system, I think, though I don't see why it makes so much difference in
> > your case.
> >
> > If you type, from the shell,
> >
> >   gdb -i=mi YOUR-BINARY
> >   r
> >
> > do you similarly see a huge output?
>
> As you know, in addition to "run", gdb-mi.el sends lots of other
> commands behind the scenes, so the above is not a faithful simulation
> of what happens when GDB is run by Emacs.  But I agree that if the
> above produces similarly voluminous output, we cannot really blame
> gdb-mi.el.
>
>