Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)

[Nick Roberts]

 > 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