bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10580: 24.0.92; gdb initialization takes more than one minute at 100


From: Dov Grobgeld
Subject: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU
Date: Wed, 9 May 2012 00:07:05 +0300

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 <address@hidden> wrote:
> From: Chong Yidong <address@hidden>
> Date: Wed, 09 May 2012 00:25:00 +0800
> Cc: address@hidden
>
> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]