[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
From: |
Nick Roberts |
Subject: |
Re: gud : Phase error in gdb-pre-prompt (got pre-emacs) |
Date: |
Tue, 1 Jul 2008 10:15:20 +1200 |
> I have a similar behaviour except that once the file is loaded emacs says
> within the square brackets:
>
> [Initializing...]
>
> forever. I need to do 'run', C-c Cc, <wait for ~10 seconds>. After that emacs
> says
>
> [ready]
>
> If I simply do 'run', emacs only show [Initializing...] forever.
>
> >
> > There are several factors that might make this slow:
> >
> > 1) An executable that was created from a large number of files.
>
> That's probably is the case since I'm loading Linux kernel.
>
> > 2) Using stabs debug format.
>
> I don't
>
> > 3) Using an old PC.
>
> I don't
You don't need all three and debugging the kernel is surely different to
debugging a program running within the oprating system.
> > If this is the problem I can post a patch that might speed things up but
> > just turning off gud-tooltip-mode might help.
> >
>
> turning off gud-tooltip-mode doesn't help.
I think this one only makes a difference if you are already visiting a large
number of files that form part of the executable.
> > If you still get an error after waiting for "ready":
> >
> > 1) Set gdb-enable-debug to t using M-x set-variable.
> > 2) Do M-x gdb and enter "run" in the GUD buffer to get the error.
> > 4) Post the value of gdb-debug-log (you can use `C-h v') to the list
> > (or just to me if it's large).
>
> Here it is:
>
> gdb-debug-log is a variable defined in `gdb-ui.el'.
> Its value is
> ((recv . "\n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n")
> (recv .
> "\n^Z^Zpost-prompt\n^done,frame={level=\"0\",addr=\"0x84002000\",func=\"_stext\"}\n(gdb)
> \n")
> (send-item "server interpreter mi -stack-info-frame\n" gdb-get-version))
That shows to me that execution has already begun and is in the function
_stext, so "run" wouldn't be an appropriate command to send anyway. It normally
starts (ends) like this:
...
(recv . "\n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n")
(recv . "\n^Z^Zpost-prompt\n")
(send-item "set width 0\n" ignore)
(recv . "\n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n")
(recv . "\n^Z^Zpost-prompt\n")
(send-item "set height 0\n" ignore)
(recv . "\n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n")
(recv . "\n^Z^Zpost-prompt\n&\"\\n^Z^Zerror-begin\\n\"\n&\"No
registers.\\n\"\n~\"\\n\"\n~\"^Z^Zerror\\n\"\n^error,msg=\"No
registers.\"\n(gdb) \n")
(send-item "server interpreter mi -stack-info-frame\n" gdb-get-version))
I understand why Emacs stops sending GDB commands after -stack-info-frame in
your case. What are the values of the variables
gdb-input-queue
gdb-pending triggers
gdb-ready
gud-runnning
at this point?
Isn't the kernel debugged through a remote stub in a patched gdb (kgdb)? I've
never done it but Hidetoshi Shimokawa has a patch here
http://wiki.freebsd.org/DebugWithDcons that successfully does it using
Emacs for the FreeBSD kernel.
Also there was a thread "kgdb in emacs" in help-gnu-emacs back in April of this
year.
If you make prgress with this problem please post a description to the list (or
emacs-devel) so I can add it to the documentation.
--
Nick http://www.inet.net.nz/~nickrob