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

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

[Markus Grunwald]

Hello,

I'm not lucky with my switch from emacs21 to GNU Emacs 22.2.1
(i686-pc-linux-gnu, GTK+ Version 2.8.20): first emacs still hangs on
(next-buffer) (see earlier posting...), now gud is not working.

What I did:

>M-x gdb
>gdb --annotate=3 binary.bin

gdb loads the binary, I get the gdb prompt. Then:

Current directory is somewhere.
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc. [...]
This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db
library "/lib/tls/i686/cmov/libthread_db.so.1". 
(gdb) run
  C-c C-c  C-c C-c  C-c C-c

  C-c C-c
  C-c C-c  C-c C-c


After entering "run", I get no output from my program, it is not in "ps",
but the cpu is working 50% for about 20 seconds. I try to interrupt (C-c
C-c or via gud menu) but I only get the output in the buffer as seen
above. Gud won't react on anything I do, I can just close the buffer and
try it again.

Looking into the messages buffer, I see this:

Loading gdb-ui...done
error in process filter: gdb-pre-prompt: Phase error in gdb-pre-prompt
(got pre-emacs) error in process filter: Phase error in gdb-pre-prompt
(got pre-emacs)

It seems to work when I start gdb without binary and load it from gdb with
(gdb) file binary.bin
(gdb) run

Pure gdb works like a charm, of course.

This is not an environment I can work with. But I like some emacs22 very
much (e.g. the watch list in the speedbar or the red dots for breakpoints),
so I really hope you can help me with this...


Many TIA,

Markus

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

[Nick Roberts]

 > I'm not lucky with my switch from emacs21 to GNU Emacs 22.2.1
 > (i686-pc-linux-gnu, GTK+ Version 2.8.20): first emacs still hangs on
 > (next-buffer) (see earlier posting...), now gud is not working.
 > 
 > What I did:
 > 
 > >M-x gdb
 > >gdb --annotate=3 binary.bin
 > 
 > gdb loads the binary, I get the gdb prompt. Then:
 > 
 > Current directory is somewhere.
 > GNU gdb 6.6
 > Copyright (C) 2006 Free Software Foundation, Inc. [...]
 > This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db
 > library "/lib/tls/i686/cmov/libthread_db.so.1". 
 > (gdb) run
 >   C-c C-c  C-c C-c  C-c C-c
 > 
 >   C-c C-c
 >   C-c C-c  C-c C-c

What does it say within the square brackets in the mode-line of the GUD
buffer _before_ you type `C-c C-c'?  If it says "initializing..." then it
might help to wait a bit longer until it says "ready" before typing the first
command.

There are several factors that might make this slow:

1) An executable that was created from a large number of files.
2) Using stabs debug format.
3) Using an old PC.

If this is the problem I can post a patch that might speed things up but
just turning off gud-tooltip-mode might help.

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).

-- 
Nick                                           http://www.inet.net.nz/~nickrob

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

[Markus Grunwald]

On Fri, 27 Jun 2008 22:18:11 +1200, Nick Roberts wrote:

> What does it say within the square brackets in the mode-line of the GUD
> buffer _before_ you type `C-c C-c'?  If it says "initializing..." then it
> might help to wait a bit longer until it says "ready" before typing the first
> command.

You are right: After loading the binary it says "initialising...". After 1
Minute 30 seconds (!) it turns to "ready" and I can work normally.

I tried again with "gdb --annotate=3" (= without binary as parameter) and
loaded the binary with
(gdb) file binary.bin
There was no "initialising..." message visible and I could start
immediately. What's the difference ?

> There are several factors that might make this slow:
> 
> 1) An executable that was created from a large number of files.

gru@PT-AGCMLX1 >find . \( -name \*.cpp -o -name \*.h \) | wc -l
3072

Would this qualify as "large" ? ;)

> 2) Using stabs debug format.

Hmm, not sure. I just compiled with gcc-2.95 (yes, that old....) and "-g".
"info gcc" gives me the impression that this means stabs or gdb ...

> 3) Using an old PC.

gru@CMDevLin2 >cat /proc/cpuinfo 
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz
cpu MHz         : 2405.535
cache size      : 512 KB

Not that old...
CPU is at 20% while "initialising....".
/home is mounted via nfs but I can hardly see any network activity while
"initialising..."

> If this is the problem I can post a patch that might speed things up but
I would try this :)

> just turning off gud-tooltip-mode might help.

"gud-tooltip-mode is a variable defined in `gud.el'.
Its value is nil"

So it is turned off.
 
Many thanks for your help :) For the time beeing, I'll just load the
binary from within gdb. Everything seems to work and I don't have to wait
1:30 minutes. If my colleages see this, I will have to hear their laughter
till the end of days ;)

cu
-- 
Markus

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

[Nick Roberts]

 > I tried again with "gdb --annotate=3" (= without binary as parameter) and
 > loaded the binary with
 > (gdb) file binary.bin
 > There was no "initialising..." message visible and I could start
 > immediately. What's the difference ?

Emacs just builds a list of filenames from GDB that were used to build the
executable.  If you specify the name later in the GUD buffer, it doesn't build
that list.  That makes it quicker but if there are relevant files in existing
buffers or you visit them they won't be enabled for debugging, e.g., you won't
be able to click in the fringe to set a breakpoint until execution has already
stopped there.

 > > There are several factors that might make this slow:
 > > 
 > > 1) An executable that was created from a large number of files.
 > 
 > gru@PT-AGCMLX1 >find . \( -name \*.cpp -o -name \*.h \) | wc -l
 > 3072
 > 
 > Would this qualify as "large" ? ;)

A similar command for Emacs gives 375, so, ..err yes, that does sound rather
large.

 > > 2) Using stabs debug format.
 > 
 > Hmm, not sure. I just compiled with gcc-2.95 (yes, that old....) and "-g".
 > "info gcc" gives me the impression that this means stabs or gdb ...

In GDB, once execution has started, e.g., after hitting a breakpoint, do

(gdb) info source
Current source file is myprog.c
Compilation directory is /home/nickrob
Located in /home/nickrob/myprog.c
Contains 262 lines.
Source language is c.
Compiled with DWARF 2 debugging format.
              ^^^^^^^
Includes preprocessor macro info.

Stabs is an old debug format and I suspect it might be the default for gcc-2.95.
Maybe you can compile with DWARF 2 instead (using `-gdwarf-2') then Emacs should
start up more qickly.

 > > 3) Using an old PC.
 > 
 > gru@CMDevLin2 >cat /proc/cpuinfo 
 > vendor_id       : GenuineIntel
 > cpu family      : 15
 > model           : 2
 > model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz
 > cpu MHz         : 2405.535
 > cache size      : 512 KB
 > 
 > Not that old...
 > CPU is at 20% while "initialising....".
 > /home is mounted via nfs but I can hardly see any network activity while
 > "initialising..."

By old, I guess I mean 100MHz.  It looks like it might not be CPU bound,
anyway.

 > > If this is the problem I can post a patch that might speed things up but
 > I would try this :)
 > 
 > > just turning off gud-tooltip-mode might help.
 > 
 > "gud-tooltip-mode is a variable defined in `gud.el'.
 > Its value is nil"
 > 
 > So it is turned off.
 >  
 > Many thanks for your help :) For the time beeing, I'll just load the
 > binary from within gdb. Everything seems to work and I don't have to wait
 > 1:30 minutes. If my colleages see this, I will have to hear their laughter
 > till the end of days ;)

I think that has the same effect as my patch would, i.e., just not build the
list.  It just means that initially you need to set breakpoints, etc, from the
GUD buffer

All these tasks that Emacs performs behind the users back should be benchmarked
and optimised really, but I just haven't found the time.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

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

[Francis Moreau]

Hello,

On Fri, Jun 27, 2008 at 12:18 PM, Nick Roberts <nickrob@snap.net.nz> wrote:
>  > I'm not lucky with my switch from emacs21 to GNU Emacs 22.2.1
>  > (i686-pc-linux-gnu, GTK+ Version 2.8.20): first emacs still hangs on
>  > (next-buffer) (see earlier posting...), now gud is not working.
>  >
>  > What I did:
>  >
>  > >M-x gdb
>  > >gdb --annotate=3 binary.bin
>  >
>  > gdb loads the binary, I get the gdb prompt. Then:
>  >
>  > Current directory is somewhere.
>  > GNU gdb 6.6
>  > Copyright (C) 2006 Free Software Foundation, Inc. [...]
>  > This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db
>  > library "/lib/tls/i686/cmov/libthread_db.so.1".
>  > (gdb) run
>  >   C-c C-c  C-c C-c  C-c C-c
>  >
>  >   C-c C-c
>  >   C-c C-c  C-c C-c
>

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

>
> 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.

> 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))


thanks,
-- 
Francis

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

[Markus Grunwald]

On Sat, 28 Jun 2008 11:49:53 +1200, Nick Roberts wrote:


>  > > 2) Using stabs debug format.
>  > 
>  > Hmm, not sure. I just compiled with gcc-2.95 (yes, that old....) and "-g".
>  > "info gcc" gives me the impression that this means stabs or gdb ...

Yes, I was using stabs format. So I switched to dwarf-2 but the situation
is worse because now gdb itself takes ages to load the binary :( Compared
to this, the "initialising..." time seemed short. Seems that I'll have to
continue with stabs and load the binary manually...

Nevertheless, thanks for your help !

cu
Markus

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

[Francis Moreau]

On Mon, Jun 30, 2008 at 2:45 PM, Markus Grunwald <markus.grunwald@gmx.de> wrote:
> On Sat, 28 Jun 2008 11:49:53 +1200, Nick Roberts wrote:
>
>
>>  > > 2) Using stabs debug format.
>>  >
>>  > Hmm, not sure. I just compiled with gcc-2.95 (yes, that old....) and "-g".
>>  > "info gcc" gives me the impression that this means stabs or gdb ...
>
> Yes, I was using stabs format. So I switched to dwarf-2 but the situation
> is worse because now gdb itself takes ages to load the binary :( Compared
> to this, the "initialising..." time seemed short. Seems that I'll have to
> continue with stabs and load the binary manually...
>

looks like with hitting the same issue....

-- 
Francis

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

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

[Nick Roberts]

 > Yes, I was using stabs format. So I switched to dwarf-2 but the situation
 > is worse because now gdb itself takes ages to load the binary :( Compared
 > to this, the "initialising..." time seemed short. Seems that I'll have to
 > continue with stabs and load the binary manually...

OK.  That's not very satisfactory because the buffers won't have the name of
the executable in the mode-line.  In CVS Emacs, I've created a booolean
variable, gdb-create-source-file-list, that determines whether or not Emacs
creates a list of files.  It probably won't be used much but it's default value
is t, so those who don't need it won't need to know about it

-- 
Nick                                           http://www.inet.net.nz/~nickrob

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

[Francis Moreau]

Hello,

On Tue, Jul 1, 2008 at 12:15 AM, Nick Roberts <nickrob@snap.net.nz> wrote:
>  > 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.

Well actually I lied, I don't do 'run' but 'continue' but I've never
figured out why...

> 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.

Note that I can't issue any command when emacs is in this state.
They just get stuck.

> What are the values of the variables
>
> gdb-input-queue
> gdb-pending triggers
> gdb-ready
> gud-runnning
>
> at this point?
>

gdb-input-queue is a variable defined in `gdb-ui.el'.
Its value is
(("server info source\n" gdb-source-info)
 ("server list\n" ignore)
 ("server interpreter mi \"-file-list-exec-source-files\"\n"
gdb-set-gud-minor-mode-existing-buffers-1)
 ("server interpreter mi -data-list-register-names\n" gdb-get-register-names)
 ("set width 0\n" ignore)
 ("set height 0\n" ignore))


gdb-pending-triggers is a variable defined in `gdb-ui.el'.
Its value is nil

gdb-ready is a variable defined in `gud.el'.
Its value is nil

gud-running is a variable defined in `gud.el'.
Its value is nil


> Isn't the kernel debugged through a remote stub in a patched gdb (kgdb)?

Yes probably, I'm using a gdb patched by a third party but don't know and can't
figure out what has been patched...

>
> 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.

No problem. Which documentation are you talking about BTW ?

But I can add 2 more info about this issue:

First, starting gdb from a shell works fine.

Second point is emacs 21 used to work.

Thanks
-- 
Francis

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

[Nick Roberts]

 > > 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.
 > 
 > Well actually I lied, I don't do 'run' but 'continue' but I've never
 > figured out why...

If you connect to a remote target, it's already running and it stops when you
connect to it.  I presume it's the same for a kernel.


 > > 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

Sorry, I mean I don't understand
         ^^^^^

 > ...
 > gdb-input-queue is a variable defined in `gdb-ui.el'.
 > Its value is
 > (("server info source\n" gdb-source-info)
 >  ("server list\n" ignore)
 >  ("server interpreter mi \"-file-list-exec-source-files\"\n"
 > gdb-set-gud-minor-mode-existing-buffers-1)
 >  ("server interpreter mi -data-list-register-names\n" gdb-get-register-names)
 >  ("set width 0\n" ignore)
 >  ("set height 0\n" ignore))

This should be nil.


 > > Isn't the kernel debugged through a remote stub in a patched gdb (kgdb)?
 > 
 > Yes probably, I'm using a gdb patched by a third party but don't know and
 > can't figure out what has been patched...

Then the patch may change behaviour in other ways.  I suspect that it's not
issuing some of the prompt annotations.  A distributed patched gdb is covered
by GPL so presumably you have access to the source code.  What version of
gdb is itbased on? and who are the third party?


 > > 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.
 > 
 > No problem. Which documentation are you talking about BTW ?

If it's general, I could say something in the manual.  If it's specialised
I could put it in the commentary of gdb-ui.el.


 > But I can add 2 more info about this issue:
 > 
 > First, starting gdb from a shell works fine.

I still don't know how you are using gdb.  Presumably it's not running on the
same machine as the kernel that you are debugging.  How do you start
gdb/connect to the kernel from a shell?


 > Second point is emacs 21 used to work.

It's a different mode.  With M-x gdb, if you use "gdb --fullname" instead of
"gdb --annotate=3" with Emacs 22.x it should work as before.  With Emacs 23,
i.e. Emacs in CVS, you have to use M-x gud-gdb


-- 
Nick                                           http://www.inet.net.nz/~nickrob

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

[Markus Grunwald]

Hello,

>> Yes, I was using stabs format. So I switched to dwarf-2 but the situation
>  > is worse because now gdb itself takes ages to load the binary :( Compared
>  > to this, the "initialising..." time seemed short. Seems that I'll have to
>  > continue with stabs and load the binary manually...
> 
> OK.  That's not very satisfactory because the buffers won't have the name of
> the executable in the mode-line.

I can live with this.
But what I would like to have is this: When I start gdb now (M-x gdb), I
get the gdb command line with a suggestion of the file to debug (which is,
in my case, always wrong):

gdb --annotate=3 filename.cpp

 So I have to delete the "filename.cpp" and hit enter.

Is it possible to suppress this filename so that I can immediately hit
enter ? This would already help a lot...

cu
-- 
Markus

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

[Nick Roberts]

 > But what I would like to have is this: When I start gdb now (M-x gdb), I
 > get the gdb command line with a suggestion of the file to debug (which is,
 > in my case, always wrong):
 > 
 > gdb --annotate=3 filename.cpp
 > 
 >  So I have to delete the "filename.cpp" and hit enter.
 > 
 > Is it possible to suppress this filename so that I can immediately hit
 > enter ? This would already help a lot...

Your situation is somewhat unusual so I'm not planning to accomodate this in
Emacs.  However, it's quite easy for you to patch gud.el like below.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


--- gud.el	13 Jun 2008 09:07:24 +1200	1.155
+++ gud.el	03 Jul 2008 12:16:09 +1200	
@@ -694,16 +694,7 @@ The option \"--fullname\" must be includ
     (read-from-minibuffer
      (format "Run %s (like this): " minor-mode)
      (or (car-safe (symbol-value hist-sym))
-	 (concat (or cmd-name (symbol-name minor-mode))
-		 " "
-		 (or init
-		     (let ((file nil))
-		       (dolist (f (directory-files default-directory) file)
-			 (if (and (file-executable-p f)
-				  (not (file-directory-p f))
-				  (or (not file)
-				      (file-newer-than-file-p f file)))
-			     (setq file f)))))))
+	 (concat (or cmd-name (symbol-name minor-mode)) " " (or init)))
      gud-minibuffer-local-map nil
      hist-sym)))

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

[hui wang]

[-- Attachment #1: Type: text/plain, Size: 3570 bytes --]

2008/6/28 Nick Roberts <nickrob@snap.net.nz>:

>  > I tried again with "gdb --annotate=3" (= without binary as parameter)
> and
>  > loaded the binary with
>  > (gdb) file binary.bin
>  > There was no "initialising..." message visible and I could start
>  > immediately. What's the difference ?
>
> Emacs just builds a list of filenames from GDB that were used to build the
> executable.  If you specify the name later in the GUD buffer, it doesn't
> build
> that list.  That makes it quicker but if there are relevant files in
> existing
> buffers or you visit them they won't be enabled for debugging, e.g., you
> won't
> be able to click in the fringe to set a breakpoint until execution has
> already
> stopped there.
>
How to disable emacs from "builds a list of filenames from GDB?"
I have the same problem, and You have given me similiar solution. But it
does not work.
So now, I prefer emacs not build it. Maybe there should be a flag for it.

>
>  > > There are several factors that might make this slow:
>  > >
>  > > 1) An executable that was created from a large number of files.
>  >
>  > gru@PT-AGCMLX1 >find . \( -name \*.cpp -o -name \*.h \) | wc -l
>  > 3072
>  >
>  > Would this qualify as "large" ? ;)
>
> A similar command for Emacs gives 375, so, ..err yes, that does sound
> rather
> large.
>
>  > > 2) Using stabs debug format.
>  >
>  > Hmm, not sure. I just compiled with gcc-2.95 (yes, that old....) and
> "-g".
>  > "info gcc" gives me the impression that this means stabs or gdb ...
>
> In GDB, once execution has started, e.g., after hitting a breakpoint, do
>
> (gdb) info source
> Current source file is myprog.c
> Compilation directory is /home/nickrob
> Located in /home/nickrob/myprog.c
> Contains 262 lines.
> Source language is c.
> Compiled with DWARF 2 debugging format.
>              ^^^^^^^
> Includes preprocessor macro info.
>
> Stabs is an old debug format and I suspect it might be the default for
> gcc-2.95.
> Maybe you can compile with DWARF 2 instead (using `-gdwarf-2') then Emacs
> should
> start up more qickly.
>
>  > > 3) Using an old PC.
>  >
>  > gru@CMDevLin2 >cat /proc/cpuinfo
>  > vendor_id       : GenuineIntel
>  > cpu family      : 15
>  > model           : 2
>  > model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz
>  > cpu MHz         : 2405.535
>  > cache size      : 512 KB
>  >
>  > Not that old...
>  > CPU is at 20% while "initialising....".
>  > /home is mounted via nfs but I can hardly see any network activity while
>  > "initialising..."
>
> By old, I guess I mean 100MHz.  It looks like it might not be CPU bound,
> anyway.
>
>  > > If this is the problem I can post a patch that might speed things up
> but
>  > I would try this :)
>  >
>  > > just turning off gud-tooltip-mode might help.
>  >
>  > "gud-tooltip-mode is a variable defined in `gud.el'.
>  > Its value is nil"
>  >
>  > So it is turned off.
>  >
>  > Many thanks for your help :) For the time beeing, I'll just load the
>  > binary from within gdb. Everything seems to work and I don't have to
> wait
>  > 1:30 minutes. If my colleages see this, I will have to hear their
> laughter
>  > till the end of days ;)
>
> I think that has the same effect as my patch would, i.e., just not build
> the
> list.  It just means that initially you need to set breakpoints, etc, from
> the
> GUD buffer
>
> All these tasks that Emacs performs behind the users back should be
> benchmarked
> and optimised really, but I just haven't found the time.
>
> --
> Nick
> http://www.inet.net.nz/~nickrob <http://www.inet.net.nz/%7Enickrob>
>
>
>

[-- Attachment #2: Type: text/html, Size: 5181 bytes --]

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

[Nick Roberts]

 > > Emacs just builds a list of filenames from GDB that were used to build the
 > > executable.  If you specify the name later in the GUD buffer, it doesn't
 > > build
 > > that list.  That makes it quicker but if there are relevant files in
 > > existing
 > > buffers or you visit them they won't be enabled for debugging, e.g., you
 > > won't
 > > be able to click in the fringe to set a breakpoint until execution has
 > > already
 > > stopped there.
 > >
 > How to disable emacs from "builds a list of filenames from GDB?"
 > I have the same problem, and You have given me similiar solution. But it
 > does not work.

If it doesn't work then maybe it's a different problem.  I suspect not though.
What happens if you use Markus' approach below?

    It seems to work when I start gdb without binary and load it from gdb with
    (gdb) file binary.bin
    (gdb) run

 > So now, I prefer emacs not build it. Maybe there should be a flag for it.

As I explained to Markus, I have created a flag, gdb-create-source-file-list,
but you need to checkout Emacs from the CVS repository at Savannah to get it.
Be aware, though, that it works like the patch that I posted to you last time.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

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

[Markus Grunwald]

Hello,

> Your situation is somewhat unusual so I'm not planning to accomodate this in
> Emacs.  However, it's quite easy for you to patch gud.el like below.

Thanks, I'll try this soon.

cu
-- 
Markus

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

[Francis Moreau]

Hello

[ sorry for the delayed reply ]

On Wed, Jul 2, 2008 at 12:41 AM, Nick Roberts <nickrob@snap.net.nz> wrote:
>  > > 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
>
> Sorry, I mean I don't understand
>         ^^^^^
>

any debug mode we could use ?

>  > ...
>  > gdb-input-queue is a variable defined in `gdb-ui.el'.
>  > Its value is
>  > (("server info source\n" gdb-source-info)
>  >  ("server list\n" ignore)
>  >  ("server interpreter mi \"-file-list-exec-source-files\"\n"
>  > gdb-set-gud-minor-mode-existing-buffers-1)
>  >  ("server interpreter mi -data-list-register-names\n" gdb-get-register-names)
>  >  ("set width 0\n" ignore)
>  >  ("set height 0\n" ignore))
>
> This should be nil.
>
>
>  > > Isn't the kernel debugged through a remote stub in a patched gdb (kgdb)?
>  >
>  > Yes probably, I'm using a gdb patched by a third party but don't know and
>  > can't figure out what has been patched...
>
> Then the patch may change behaviour in other ways.  I suspect that it's not
> issuing some of the prompt annotations.  A distributed patched gdb is covered
> by GPL so presumably you have access to the source code.  What version of
> gdb is itbased on? and who are the third party?
>

GNU gdb STMicroelectronics/Linux Base 6.5-24 [build Oct 24 2007]

coming from

http://www.stlinux.com/download/

>
>  > But I can add 2 more info about this issue:
>  >
>  > First, starting gdb from a shell works fine.
>
> I still don't know how you are using gdb.  Presumably it's not running on the
> same machine as the kernel that you are debugging.  How do you start
> gdb/connect to the kernel from a shell?
>

Sorry, gdb is connecting to a probe. I suppose gdb has been patched to do
that.

I can show you what gdb prompt in a shell if you want.

>
>  > Second point is emacs 21 used to work.
>
> It's a different mode.  With M-x gdb, if you use "gdb --fullname" instead of
> "gdb --annotate=3" with Emacs 22.x it should work as before.  With Emacs 23,
> i.e. Emacs in CVS, you have to use M-x gud-gdb

hmm:

sh4-linux-gdb: unrecognized option '--fullname'

thanks
-- 
Francis

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

[Nick Roberts]

 > >  > Yes probably, I'm using a gdb patched by a third party but don't know
 > >  > and can't figure out what has been patched...
 > >
 > > Then the patch may change behaviour in other ways.  I suspect that it's
 > > not issuing some of the prompt annotations.  A distributed patched gdb is
 > > covered by GPL so presumably you have access to the source code.  What
 > > version of gdb is itbased on? and who are the third party?
 > >
 > 
 > GNU gdb STMicroelectronics/Linux Base 6.5-24 [build Oct 24 2007]
 > 
 > coming from
 > 
 > http://www.stlinux.com/download/

OK.  In that case it might be a good idea to try the mode in the package gdb-mi
at ELPA (http://tromey.com/elpa/) which uses GDB/MI instead of annotations.  If
you are familiar with Emacs, this is very straightforward to install/uninstall.
This will replace the current mode, anyway, as annotations are being
deprecated.  Also I know that there are at least two people (Denis Pilat and
Andrew Stubbs) from STMicroelectronics who have been active on the GDB mailing
list and who have contributed to GDB/MI. If this works for you please report
back to this list.

 >...
 > > It's a different mode.  With M-x gdb, if you use "gdb --fullname" instead of
 > > "gdb --annotate=3" with Emacs 22.x it should work as before.  With Emacs 23,
 > > i.e. Emacs in CVS, you have to use M-x gud-gdb
 > 
 > hmm:
 > 
 > sh4-linux-gdb: unrecognized option '--fullname'

You could try '--annotations=1' which is an alias for '--fullname' but it looks
like this version might not support it anyway.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

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

[Francis Moreau]

On Mon, Jul 7, 2008 at 11:19 AM, Nick Roberts <nickrob@snap.net.nz> wrote:
> OK.  In that case it might be a good idea to try the mode in the package gdb-mi
> at ELPA (http://tromey.com/elpa/) which uses GDB/MI instead of annotations.  If
> you are familiar with Emacs, this is very straightforward to install/uninstall.

well I'll probably still use the old annotation since I don't have time to
play with this.

> This will replace the current mode, anyway, as annotations are being
> deprecated.

OK

thanks
-- 
Francis

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

[Francis Moreau]

Hi !

On Mon, Jul 7, 2008 at 11:19 AM, Nick Roberts <nickrob@snap.net.nz> wrote:
>  > >  > Yes probably, I'm using a gdb patched by a third party but don't know
>  > >  > and can't figure out what has been patched...
>  > >
>  > > Then the patch may change behaviour in other ways.  I suspect that it's
>  > > not issuing some of the prompt annotations.  A distributed patched gdb is
>  > > covered by GPL so presumably you have access to the source code.  What
>  > > version of gdb is itbased on? and who are the third party?
>  > >
>  >
>  > GNU gdb STMicroelectronics/Linux Base 6.5-24 [build Oct 24 2007]
>  >
>  > coming from
>  >
>  > http://www.stlinux.com/download/
>
> OK.  In that case it might be a good idea to try the mode in the package gdb-mi
> at ELPA (http://tromey.com/elpa/) which uses GDB/MI instead of annotations.  If
> you are familiar with Emacs, this is very straightforward to install/uninstall.
> This will replace the current mode, anyway, as annotations are being
> deprecated.  Also I know that there are at least two people (Denis Pilat and
> Andrew Stubbs) from STMicroelectronics who have been active on the GDB mailing
> list and who have contributed to GDB/MI. If this works for you please report
> back to this list.
>

FYI, I have exactly the same issue when using KGDB (as gdbserver)...

gdb is started from emacs by issuing: gdb --annotate=3 vmlinux

host and client are PC (x86-64)

Thanks
-- 
Francis