RFA (?) Annotate Level 3 patch

RFA (?) Annotate Level 3 patch

[Nick Roberts]

The annotation frame-begin is not needed, per se, by Emacs (gdb-ui.el) but it
is used to determine that the I/O for the subprocess is now GDB, not the
program being debugged i.e as a stopped annotation. In many cases there is
another annotation e.g breakpoint to tell Emacs this. However, in some cases,
e.g after `finish' or `return', frame-begin is the first `stopping' annotation
that GDB issues before printing (out frame details).

So I propose the patch below. It means that the stopped annotation gets printed
twice but that doesn't matter to Emacs. It's not elegant but, hey, it works!

I think Emacs is the only application that is interested in level 3
annotations so could "-gnuemacs" be made an alias option for "-annotate=3"?
From GDB's point of view this would discourage new applications form using
it. From Emacs point of view, it would legitimise changes that we would wish
to make.

Nick



--- annotate.c.~1.5.60.1.~	2003-07-29 14:35:47.000000000 +0100
+++ annotate.c	2003-08-04 19:44:02.000000000 +0100
@@ -436,6 +436,7 @@
       print_address_numeric (pc, 0, gdb_stdout);
       printf_filtered ("\n");
     }
+  if (annotation_level == 3) printf_filtered ("\n\032\032stopped\n");
 }
 
 void

Re: RFA (?) Annotate Level 3 patch

[Andrew Cagney]

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

(Working through the old ones :-()
Nick,

Can you post a log with/with-out this patch to illustrate what's 
happening.  You're right - emacs should see "stopped" first but there 
might be a better long-term way to do this.

I suspect this will mean playing with the print-stop-reason code.

Andrew

[-- Attachment #2: mailbox-message://ac131313@movemail/fsf/gdb/patches#125619 --]
[-- Type: message/rfc822, Size: 3665 bytes --]

From: Nick Roberts <nick@nick.uklinux.net>
To: gdb-patches@sources.redhat.com
Subject: RFA (?) Annotate Level 3 patch
Date: Tue, 5 Aug 2003 21:04:56 +0100
Message-ID: <16176.3560.65649.7079@nick.uklinux.net>


The annotation frame-begin is not needed, per se, by Emacs (gdb-ui.el) but it
is used to determine that the I/O for the subprocess is now GDB, not the
program being debugged i.e as a stopped annotation. In many cases there is
another annotation e.g breakpoint to tell Emacs this. However, in some cases,
e.g after `finish' or `return', frame-begin is the first `stopping' annotation
that GDB issues before printing (out frame details).

So I propose the patch below. It means that the stopped annotation gets printed
twice but that doesn't matter to Emacs. It's not elegant but, hey, it works!

I think Emacs is the only application that is interested in level 3
annotations so could "-gnuemacs" be made an alias option for "-annotate=3"?
From GDB's point of view this would discourage new applications form using
it. From Emacs point of view, it would legitimise changes that we would wish
to make.

Nick



--- annotate.c.~1.5.60.1.~	2003-07-29 14:35:47.000000000 +0100
+++ annotate.c	2003-08-04 19:44:02.000000000 +0100
@@ -436,6 +436,7 @@
       print_address_numeric (pc, 0, gdb_stdout);
       printf_filtered ("\n");
     }
+  if (annotation_level == 3) printf_filtered ("\n\032\032stopped\n");
 }
 
 void

Annotations

[Nick Roberts]

 > Can you post a log with/with-out this patch to illustrate what's 
 > happening.  You're right - emacs should see "stopped" first but there 
 > might be a better long-term way to do this.
 > 
 > I suspect this will mean playing with the print-stop-reason code.

Please ignore the patch (I should have said it was inelegant and did not work).
The bug is real, however. See below.

Similar (stream separation) problems occur with GDB output running
multi-threaded programs. However, I don't know how much effort you are
prepared to spend on annotations. If you guide me I can look at annotate.c.
Jim Blandy has suggested using the tty command for stream separation but
presumably this wouldn't work on Windows.


Nick



example.c:

myproc()
{
  int j;
  j = 1;
}

main()
{
  int i;
  i = 1;
  myproc();
  i = 2;
}

Start like:
gdb -ann=2 example

Type:
set height 0
b myproc
run
finish


Output:
(Frame details are given before the stopped annotation and so appear to
be program output)

...

^Z^Zstarting

^Z^Zframes-invalid

^Z^Zframes-invalid

^Z^Zframe-begin 0 0x8048336

^Z^Zframe-function-name
main
^Z^Zframe-args
 ()
^Z^Zframe-source-begin
 at 
^Z^Zframe-source-file
example.c
^Z^Zframe-source-file-end
:
^Z^Zframe-source-line
12
^Z^Zframe-source-end


^Z^Zsource /home/nick/example.c:12:71:beg:0x8048336

^Z^Zframe-end

^Z^Zstopped

...

Re: RFA (?) Annotate Level 3 patch

[Nick Roberts]

 > Can you post a log with/with-out this patch to illustrate what's 
 > happening.  You're right - emacs should see "stopped" first but there 
 > might be a better long-term way to do this.
 > 
 > I suspect this will mean playing with the print-stop-reason code.

Moving annotate_stopped to the start of normal_stop seems to do the right
thing. It might be bad practice, however, to break existing functionality so a
better solution might be to create a new annotation there - aargh! - called
stopping, say, instead. However, remember that I will have reduced my initial
set of 25 annotations to 14. They would be:


    pre-prompt            prompt            post-prompt
    commands              overload-choice   query
    prompt-for-continue   source            starting
    exited                signalled         signal
    stopped

    and stopping

And, of course, from time to time, I'm trying to get GDB/MI to work directly
with Emacs.

BTW I have seen that Vim developers are starting to use level 2 annotations
for their own front end to GDB.
( http://thread.gmane.org/gmane.editors.vim.devel/5024 )

Nick

Re: RFA (?) Annotate Level 3 patch

[Andrew Cagney]

>  > Can you post a log with/with-out this patch to illustrate what's 
>  > happening.  You're right - emacs should see "stopped" first but there 
>  > might be a better long-term way to do this.
>  > 
>  > I suspect this will mean playing with the print-stop-reason code.
> 
> Moving annotate_stopped to the start of normal_stop seems to do the right
> thing. It might be bad practice, however, to break existing functionality so a
> better solution might be to create a new annotation there - aargh! - called
> stopping, say, instead. However, remember that I will have reduced my initial
> set of 25 annotations to 14. They would be:
> 
> 
>     pre-prompt            prompt            post-prompt
>     commands              overload-choice   query
>     prompt-for-continue   source            starting
>     exited                signalled         signal
>     stopped
> 
>     and stopping

Could stopped be zapped from annotate level-3 then?

Andrew

Re: RFA (?) Annotate Level 3 patch

[Nick Roberts]

 > > Moving annotate_stopped to the start of normal_stop seems to do the right
 > > thing. It might be bad practice, however, to break existing functionality
 > > so a better solution might be to create a new annotation there - aargh! -
 > > called stopping, say, instead. However, remember that I will have reduced
 > > my initial set of 25 annotations to 14. They would be:
 > > 
 > > 
 > >     pre-prompt            prompt            post-prompt
 > >     commands              overload-choice   query
 > >     prompt-for-continue   source            starting
 > >     exited                signalled         signal
 > >     stopped
 > > 
 > >     and stopping
 > 
 > Could stopped be zapped from annotate level-3 then?

Well "stopped" is in my list above as a conservative measure to keep existing
functionality. Since all stop (normal or otherwise) seem to go through
normal_stop, I think that one annotation (called stopped or stopping) at the
start of this procedure is sufficient for my purposes.

On a related matter, as the Machine Interface evolves, Emacs will have to do
different things for different versions of GDB, so it would be helpful if
"show version" ("-gdb-show version") or a related command gave a formally
defined increasing version number. In Emacs, the last release is 21.3.1 and
the version in CVS is 21.3.50. In GDB, the last release is 6.0 but the version
in CVS is 2004-02-01-cvs, say. Also releases, like 5.3postxxxx.. exist.

Perhaps I can get a mode to work just with GDB/MI before the next release of
Emacs from HEAD, which is where my code resides. However, unlike GDB, Emacs has
no schedule ;-)

Nick

Re: RFA (?) Annotate Level 3 patch

[Bob Rossi]

> On a related matter, as the Machine Interface evolves, Emacs will have to do
> different things for different versions of GDB, so it would be helpful if
> "show version" ("-gdb-show version") or a related command gave a formally
> defined increasing version number. In Emacs, the last release is 21.3.1 and
> the version in CVS is 21.3.50. In GDB, the last release is 6.0 but the version
> in CVS is 2004-02-01-cvs, say. Also releases, like 5.3postxxxx.. exist.

This is also a real concern of mine. I would like to see a formal
printing of GDB/MI's version number. I think that starting gdb like
gdb --show-gdbmi-version should output the version in an MI parable
way. 

Also, another problem exists which Nick brings up. When distro's package 
GDB from CVS ( debian ), how should the front end determine what MI
version is being used? It is possible that the version number has not
formally changed, however several MI commands might have been modified.

In this case, it would be necessary to make all commands backwards
compatible, and the front end wouldn't be able to take advantage of
commands that might be useful.

An approach to solving this could be, when the front end wants to know
the version, GDB could print the MI version of each function it
supports. So,

gdb --show-gdbmi-version
^done,[{mi_function="-break-info",version=1},{mi_function="-break-list",version=2}]

Would this be overkill?

Also, as each MI command changes, the documentation must provide the
interface for that MI command for each version.

Bob Rossi