* gud : Phase error in gdb-pre-prompt (got pre-emacs)
@ 2008-06-27 8:52 Markus Grunwald
2008-06-27 10:18 ` Nick Roberts
[not found] ` <mailman.13892.1214569215.18990.help-gnu-emacs@gnu.org>
0 siblings, 2 replies; 20+ messages in thread
From: Markus Grunwald @ 2008-06-27 8:52 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
2008-06-27 8:52 gud : Phase error in gdb-pre-prompt (got pre-emacs) Markus Grunwald
@ 2008-06-27 10:18 ` Nick Roberts
2008-06-30 11:37 ` Francis Moreau
[not found] ` <mailman.13892.1214569215.18990.help-gnu-emacs@gnu.org>
1 sibling, 1 reply; 20+ messages in thread
From: Nick Roberts @ 2008-06-27 10:18 UTC (permalink / raw
To: Markus Grunwald; +Cc: help-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
[not found] ` <mailman.13892.1214569215.18990.help-gnu-emacs@gnu.org>
@ 2008-06-27 14:23 ` Markus Grunwald
2008-06-27 23:49 ` Nick Roberts
[not found] ` <mailman.13907.1214610613.18990.help-gnu-emacs@gnu.org>
0 siblings, 2 replies; 20+ messages in thread
From: Markus Grunwald @ 2008-06-27 14:23 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
2008-06-27 14:23 ` Markus Grunwald
@ 2008-06-27 23:49 ` Nick Roberts
2008-07-03 7:16 ` hui wang
[not found] ` <mailman.13907.1214610613.18990.help-gnu-emacs@gnu.org>
1 sibling, 1 reply; 20+ messages in thread
From: Nick Roberts @ 2008-06-27 23:49 UTC (permalink / raw
To: Markus Grunwald; +Cc: help-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
2008-06-27 10:18 ` Nick Roberts
@ 2008-06-30 11:37 ` Francis Moreau
2008-06-30 22:15 ` Nick Roberts
0 siblings, 1 reply; 20+ messages in thread
From: Francis Moreau @ 2008-06-30 11:37 UTC (permalink / raw
To: Nick Roberts; +Cc: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
[not found] ` <mailman.13907.1214610613.18990.help-gnu-emacs@gnu.org>
@ 2008-06-30 12:45 ` Markus Grunwald
2008-06-30 13:44 ` Francis Moreau
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Markus Grunwald @ 2008-06-30 12:45 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
2008-06-30 12:45 ` Markus Grunwald
@ 2008-06-30 13:44 ` Francis Moreau
2008-07-01 2:04 ` Nick Roberts
[not found] ` <mailman.14044.1214879193.18990.help-gnu-emacs@gnu.org>
2 siblings, 0 replies; 20+ messages in thread
From: Francis Moreau @ 2008-06-30 13:44 UTC (permalink / raw
To: Markus Grunwald; +Cc: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
2008-06-30 11:37 ` Francis Moreau
@ 2008-06-30 22:15 ` Nick Roberts
2008-07-01 14:07 ` Francis Moreau
0 siblings, 1 reply; 20+ messages in thread
From: Nick Roberts @ 2008-06-30 22:15 UTC (permalink / raw
To: Francis Moreau; +Cc: help-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
2008-06-30 12:45 ` Markus Grunwald
2008-06-30 13:44 ` Francis Moreau
@ 2008-07-01 2:04 ` Nick Roberts
[not found] ` <mailman.14044.1214879193.18990.help-gnu-emacs@gnu.org>
2 siblings, 0 replies; 20+ messages in thread
From: Nick Roberts @ 2008-07-01 2:04 UTC (permalink / raw
To: Markus Grunwald; +Cc: help-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
2008-06-30 22:15 ` Nick Roberts
@ 2008-07-01 14:07 ` Francis Moreau
2008-07-01 22:41 ` Nick Roberts
0 siblings, 1 reply; 20+ messages in thread
From: Francis Moreau @ 2008-07-01 14:07 UTC (permalink / raw
To: Nick Roberts; +Cc: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
2008-07-01 14:07 ` Francis Moreau
@ 2008-07-01 22:41 ` Nick Roberts
2008-07-07 7:59 ` Francis Moreau
0 siblings, 1 reply; 20+ messages in thread
From: Nick Roberts @ 2008-07-01 22:41 UTC (permalink / raw
To: Francis Moreau; +Cc: help-gnu-emacs
> > 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
[not found] ` <mailman.14044.1214879193.18990.help-gnu-emacs@gnu.org>
@ 2008-07-02 14:18 ` Markus Grunwald
2008-07-03 0:22 ` Nick Roberts
[not found] ` <mailman.14136.1215044558.18990.help-gnu-emacs@gnu.org>
0 siblings, 2 replies; 20+ messages in thread
From: Markus Grunwald @ 2008-07-02 14:18 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
2008-07-02 14:18 ` Markus Grunwald
@ 2008-07-03 0:22 ` Nick Roberts
[not found] ` <mailman.14136.1215044558.18990.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 20+ messages in thread
From: Nick Roberts @ 2008-07-03 0:22 UTC (permalink / raw
To: Markus Grunwald; +Cc: help-gnu-emacs
> 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)))
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
2008-06-27 23:49 ` Nick Roberts
@ 2008-07-03 7:16 ` hui wang
2008-07-03 7:35 ` Nick Roberts
0 siblings, 1 reply; 20+ messages in thread
From: hui wang @ 2008-07-03 7:16 UTC (permalink / raw
To: Nick Roberts; +Cc: Markus Grunwald, help-gnu-emacs
[-- 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 --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
2008-07-03 7:16 ` hui wang
@ 2008-07-03 7:35 ` Nick Roberts
0 siblings, 0 replies; 20+ messages in thread
From: Nick Roberts @ 2008-07-03 7:35 UTC (permalink / raw
To: hui wang; +Cc: Markus Grunwald, help-gnu-emacs
> > 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
[not found] ` <mailman.14136.1215044558.18990.help-gnu-emacs@gnu.org>
@ 2008-07-03 7:51 ` Markus Grunwald
0 siblings, 0 replies; 20+ messages in thread
From: Markus Grunwald @ 2008-07-03 7:51 UTC (permalink / raw
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
2008-07-01 22:41 ` Nick Roberts
@ 2008-07-07 7:59 ` Francis Moreau
2008-07-07 9:19 ` Nick Roberts
0 siblings, 1 reply; 20+ messages in thread
From: Francis Moreau @ 2008-07-07 7:59 UTC (permalink / raw
To: Nick Roberts; +Cc: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
2008-07-07 7:59 ` Francis Moreau
@ 2008-07-07 9:19 ` Nick Roberts
2008-07-15 7:49 ` Francis Moreau
2008-07-22 14:49 ` Francis Moreau
0 siblings, 2 replies; 20+ messages in thread
From: Nick Roberts @ 2008-07-07 9:19 UTC (permalink / raw
To: Francis Moreau; +Cc: help-gnu-emacs
> > > 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
2008-07-07 9:19 ` Nick Roberts
@ 2008-07-15 7:49 ` Francis Moreau
2008-07-22 14:49 ` Francis Moreau
1 sibling, 0 replies; 20+ messages in thread
From: Francis Moreau @ 2008-07-15 7:49 UTC (permalink / raw
To: Nick Roberts; +Cc: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: gud : Phase error in gdb-pre-prompt (got pre-emacs)
2008-07-07 9:19 ` Nick Roberts
2008-07-15 7:49 ` Francis Moreau
@ 2008-07-22 14:49 ` Francis Moreau
1 sibling, 0 replies; 20+ messages in thread
From: Francis Moreau @ 2008-07-22 14:49 UTC (permalink / raw
To: Nick Roberts; +Cc: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2008-07-22 14:49 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-06-27 8:52 gud : Phase error in gdb-pre-prompt (got pre-emacs) Markus Grunwald
2008-06-27 10:18 ` Nick Roberts
2008-06-30 11:37 ` Francis Moreau
2008-06-30 22:15 ` Nick Roberts
2008-07-01 14:07 ` Francis Moreau
2008-07-01 22:41 ` Nick Roberts
2008-07-07 7:59 ` Francis Moreau
2008-07-07 9:19 ` Nick Roberts
2008-07-15 7:49 ` Francis Moreau
2008-07-22 14:49 ` Francis Moreau
[not found] ` <mailman.13892.1214569215.18990.help-gnu-emacs@gnu.org>
2008-06-27 14:23 ` Markus Grunwald
2008-06-27 23:49 ` Nick Roberts
2008-07-03 7:16 ` hui wang
2008-07-03 7:35 ` Nick Roberts
[not found] ` <mailman.13907.1214610613.18990.help-gnu-emacs@gnu.org>
2008-06-30 12:45 ` Markus Grunwald
2008-06-30 13:44 ` Francis Moreau
2008-07-01 2:04 ` Nick Roberts
[not found] ` <mailman.14044.1214879193.18990.help-gnu-emacs@gnu.org>
2008-07-02 14:18 ` Markus Grunwald
2008-07-03 0:22 ` Nick Roberts
[not found] ` <mailman.14136.1215044558.18990.help-gnu-emacs@gnu.org>
2008-07-03 7:51 ` Markus Grunwald
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.