GDB/MI revisited

GDB/MI revisited

[Nick Roberts]

Andrew Cagney writes:

 > Can you post a transcript of a typical EMACS <-> GDB session?

It would depend on the user, of course, but typically GDB commands would be
passed to gdb by two means: explicitly through the GUD buffer or through a
lisp function. The latter could be invoked through the minibuffer, a key sequence
or through the toolbar.

I'm exploring two approaches:

1) Running gdb normally and accessing GDB/MI using "interpreter mi mi-command".

2) Running gdb with GDB/MI (-interp=mi) and accessing CLI using
   "-interpreter-exec console cli-command".

In both cases, the source file display is only updated if commands
are issued through a lisp function. This is because in the first case the lisp
function is bound to an mi command indirectly e.g

(gud-def gud-run    "interpreter mi -exec-run"  nil    "Run the program.")

and in the second case it is bound to one directly e.g 

(gud-def gud-run    "-exec-run"	     nil    "Run the program.")

and these output the out of bound record `*stopped' which emacs can parse for
the program location.

Conversely, in both cases, GDB commands entered through the GUD buffer do not
currently generate `*stopped' and source display is not updated.

QUESTION: Is it possible to modify GDB so that it does generate `*stopped' in
these cases?

The first case would require that a cli command generates out of bound
records. This would require a change in behaviour in gdb so need its own flag
e.g gdb -emacs

The second case would require that "-interpreter-exec console cli-command"
generates out of bound records. This could be its defined behaviour as it
probably would be appropriate to others.

Nick

Re: GDB/MI revisited

[Andrew Cagney]

> Andrew Cagney writes:
> 
>  > Can you post a transcript of a typical EMACS <-> GDB session?
> 
> It would depend on the user, of course, but typically GDB commands would be
> passed to gdb by two means: explicitly through the GUD buffer or through a
> lisp function. The latter could be invoked through the minibuffer, a key sequence
> or through the toolbar.
> 
> I'm exploring two approaches:
> 
> 1) Running gdb normally and accessing GDB/MI using "interpreter mi mi-command".

I would recommend this aproach.

Provides a path to a more incremental migration aproach.  MI can be 
exploited where it provides the greatest benefit.

It also avoids an immediate rewrite of things like the conosle and 
target I/O code.

> 2) Running gdb with GDB/MI (-interp=mi) and accessing CLI using
>    "-interpreter-exec console cli-command".

I'd recommend this aproach in new development.

> In both cases, the source file display is only updated if commands
> are issued through a lisp function. This is because in the first case the lisp
> function is bound to an mi command indirectly e.g
> 
> (gud-def gud-run    "interpreter mi -exec-run"  nil    "Run the program.")
> 
> and in the second case it is bound to one directly e.g 
> 
> (gud-def gud-run    "-exec-run"	     nil    "Run the program.")

You could even continue to use "run".

> and these output the out of bound record `*stopped' which emacs can parse for
> the program location.

To clarify one point.

GDB's biggest concern here isn't with run, et.al.   Rather it is with 
the IDEs relying on specific CLI output.  For instance, to obtain the 
information needed to display a breakpoint, a non MI IDE would issue a 
command such as:

> (top-gdb) info break
> Num Type           Disp Enb Address    What
> 1   breakpoint     keep y   0x018abe1c in internal_error at /home/scratch/GDB/sr
> c/gdb/utils.c:800
> 2   breakpoint     keep y   0x0180a04c in info_command at /home/scratch/GDB/src/
> gdb/cli/cli-cmds.c:202
>         silent
>         return

or even:

> info break
> 
> yypost-prompt
> 
> yybreakpoints-headers
> 
> yyfield 0
> Num 
> yyfield 1
> Type           
> yyfield 2
> Disp 
> yyfield 3
> Enb 
> yyfield 4
> Address    
> yyfield 5
> What
> 
> yybreakpoints-table
> 
> yyrecord
> 
> yyfield 0
> 1   
> yyfield 1
> breakpoint     
> 
> yypre-prompt-for-continue
> ---Type <return> to continue, or q <return> to quit---
> yyprompt-for-continue

(I think its funny here that it came back with the prompt - how does an 
IDE live with this? :-)
And then use custom pattern matching to extract the needed information.

If GDB finds it necessary to modify the breakpoint output (add an extra 
field, ...) it will likely break the GUIs that are dependant on it. 
This is bad since it inhibits GDB's ability to evolve it's user 
interface(1).

On the other hand, if an MI command is used vis:

> (top-gdb) interpreter-exec mi -break-list
> ^done,BreakpointTable={nr_rows="2",nr_cols="6",hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x018abe1c",func="internal_error",file="/home/scratch/GDB/src/gdb/utils.c",line="800",times="0"},bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x0180a04c",func="info_command",file="/home/scratch/GDB/src/gdb/cli/cli-cmds.c",line="202",times="0",script={"silent","return"}}]}
> (gdb) 
> (top-gdb) 

While unreadable to the naked eye it is easily parsable by software. 
Further, since the gdb.mi/* testsuite is testing this behavior the 
likelyhood of unintentional breakage is lessened (of course the MI 
interface will evolve, but the evolution can be managed).

> Conversely, in both cases, GDB commands entered through the GUD buffer do not
> currently generate `*stopped' and source display is not updated.
> 
> QUESTION: Is it possible to modify GDB so that it does generate `*stopped' in
> these cases?
> 
> The first case would require that a cli command generates out of bound
> records. This would require a change in behaviour in gdb so need its own flag
> e.g gdb -emacs
> 
> The second case would require that "-interpreter-exec console cli-command"
> generates out of bound records. This could be its defined behaviour as it
> probably would be appropriate to others.

You mean something like:

-interpreter-exec console break foo
~Breakpoint 1 created.
=breakpoint-create,breakpoint={nr=5,location=foo,file=bar.c,line=47}

That is the second change sitting on the interpreters branch.  I don't 
think it is immediatly necessary though as the imediate objective is to 
just address the problem of level two annotations littered through out 
things like the breakpoint code.

Andrew


(1) It is unfortunate that while some people are very quick to complain 
about various aspects of GDB's CLI, they are very slow when it comes to 
contributing to the hard and dirty work of breaking dependencies such as 
this that hinder both GDB's and the IDE's long term development.

Re: GDB/MI revisited

[Nick Roberts]

 > >  > Can you post a transcript of a typical EMACS <-> GDB session?
 > > 
 > > It would depend on the user, of course, but typically GDB commands would be
 > > passed to gdb by two means: explicitly through the GUD buffer or through a
 > > lisp function. The latter could be invoked through the minibuffer, a key sequence
 > > or through the toolbar.
 > > 
 > > I'm exploring two approaches:
 > > 
 > > 1) Running gdb normally and accessing GDB/MI using "interpreter mi mi-command".
 > 
 > I would recommend this aproach.
 > 
 > Provides a path to a more incremental migration aproach.  MI can be 
 > exploited where it provides the greatest benefit.
 > 
 > It also avoids an immediate rewrite of things like the conosle and 
 > target I/O code.

I would prefer this approach too since the GUD buffer would then allow
completion. However, without level 2 annotations, the CLI is useless to the
lisp package that I have written, so I don't see how an incremental migration
is possible.

 > > 2) Running gdb with GDB/MI (-interp=mi) and accessing CLI using
 > >    "-interpreter-exec console cli-command".
 > 
 > I'd recommend this aproach in new development.
 > 
 > > In both cases, the source file display is only updated if commands
 > > are issued through a lisp function. This is because in the first case the lisp
 > > function is bound to an mi command indirectly e.g
 > > 
 > > (gud-def gud-run    "interpreter mi -exec-run"  nil    "Run the program.")
 > > 
 > > and in the second case it is bound to one directly e.g 
 > > 
 > > (gud-def gud-run    "-exec-run"	     nil    "Run the program.")
 > 
 > You could even continue to use "run".

Except that the manual says:

   This mechanism is provided as an aid to developers of GDB/MI clients
and not as a reliable interface into the CLI.  Since the command is
being interpreteted in an environment that assumes GDB/MI behaviour,
the exact output of such commands is likely to end up being an
un-supported hybrid of GDB/MI and CLI output.

Also "run" generates ^done rather than *stopped and I am trying to use the
latter to update the source file display.

 > ...
 > To clarify one point.
 > 
 > GDB's biggest concern here isn't with run, et.al.   Rather it is with 
 > the IDEs relying on specific CLI output.  For instance, to obtain the 
 > information needed to display a breakpoint, a non MI IDE would issue a 
 > command such as:...

 > > ...
 > > yypre-prompt-for-continue
 > > ---Type <return> to continue, or q <return> to quit---
 > > yyprompt-for-continue
 > 
 > (I think its funny here that it came back with the prompt - how does an 
 > IDE live with this? :-)

set height 0

 > And then use custom pattern matching to extract the needed information.
 > 
 > If GDB finds it necessary to modify the breakpoint output (add an extra 
 > field, ...) it will likely break the GUIs that are dependant on it. 
 > This is bad since it inhibits GDB's ability to evolve it's user 
 > interface(1).
 > 
 > On the other hand, if an MI command is used vis:...
 > 
 > ...
 > While unreadable to the naked eye it is easily parsable by software. 
 > Further, since the gdb.mi/* testsuite is testing this behavior the 
 > likelyhood of unintentional breakage is lessened (of course the MI 
 > interface will evolve, but the evolution can be managed).

Yes. I follow this.

 > > Conversely, in both cases, GDB commands entered through the GUD buffer do not
 > > currently generate `*stopped' and source display is not updated.
 > > 
 > > QUESTION: Is it possible to modify GDB so that it does generate `*stopped' in
 > > these cases?
 > > 
 > > The first case would require that a cli command generates out of bound
 > > records. This would require a change in behaviour in gdb so need its own flag
 > > e.g gdb -emacs
 > > 
 > > The second case would require that "-interpreter-exec console cli-command"
 > > generates out of bound records. This could be its defined behaviour as it
 > > probably would be appropriate to others.
 > 
 > You mean something like:
 > 
 > -interpreter-exec console break foo
 > ~Breakpoint 1 created.
 > =breakpoint-create,breakpoint={nr=5,location=foo,file=bar.c,line=47}

I was thinking explicitly of *stopped. I haven't found a need for the others
yet.

 > That is the second change sitting on the interpreters branch.  

I've checked out interps-20030202-branch. This doesn't seem to do the above.
Should I have a different version? Does it generate the *stopped record in
the manner that I would like? Does it work with interpreter mi mi-command
also?

 > I don't think it is immediatly necessary though as the imediate objective
 > is to just address the problem of level two annotations littered through
 > out things like the breakpoint code.

I don't follow. Aren't they interconnected? I thought the idea was that the
quicker that MI got adopted the quicker level two annotations could be dropped

Nick

Re: GDB/MI revisited

[Andrew Cagney]

>  > >  > Can you post a transcript of a typical EMACS <-> GDB session?
>  > > 
>  > > It would depend on the user, of course, but typically GDB commands would be
>  > > passed to gdb by two means: explicitly through the GUD buffer or through a
>  > > lisp function. The latter could be invoked through the minibuffer, a key sequence
>  > > or through the toolbar.
>  > > 
>  > > I'm exploring two approaches:
>  > > 
>  > > 1) Running gdb normally and accessing GDB/MI using "interpreter mi mi-command".
>  > 
>  > I would recommend this aproach.
>  > 
>  > Provides a path to a more incremental migration aproach.  MI can be 
>  > exploited where it provides the greatest benefit.
>  > 
>  > It also avoids an immediate rewrite of things like the conosle and 
>  > target I/O code.
> 
> I would prefer this approach too since the GUD buffer would then allow
> completion. However, without level 2 annotations, the CLI is useless to the
> lisp package that I have written, so I don't see how an incremental migration
> is possible.

Why exactly is it useless?  Using both [deprecated] level 2 annotations 
and "interpreter mi ..." simultaneously.

>  > > 2) Running gdb with GDB/MI (-interp=mi) and accessing CLI using
>  > >    "-interpreter-exec console cli-command".
>  > 
>  > I'd recommend this aproach in new development.
>  > 
>  > > In both cases, the source file display is only updated if commands
>  > > are issued through a lisp function. This is because in the first case the lisp
>  > > function is bound to an mi command indirectly e.g
>  > > 
>  > > (gud-def gud-run    "interpreter mi -exec-run"  nil    "Run the program.")
>  > > 
>  > > and in the second case it is bound to one directly e.g 
>  > > 
>  > > (gud-def gud-run    "-exec-run"	     nil    "Run the program.")
>  > 
>  > You could even continue to use "run".
> 
> Except that the manual says:
> 
>    This mechanism is provided as an aid to developers of GDB/MI clients
> and not as a reliable interface into the CLI.  Since the command is
> being interpreteted in an environment that assumes GDB/MI behaviour,
> the exact output of such commands is likely to end up being an
> un-supported hybrid of GDB/MI and CLI output.
> 
> Also "run" generates ^done rather than *stopped and I am trying to use the
> latter to update the source file display.

The manual is refering to this behavior:

(gdb)
target sim
&"target sim\n"
~"Connected to the simulator.\n"
^done
(gdb)

The new behavior vis:

(gdb)
-interpreter-exec console "target sim"
~"Connected to the simulator.\n"
^done
(gdb)

is documented and supported.

>  > While unreadable to the naked eye it is easily parsable by software. 
>  > Further, since the gdb.mi/* testsuite is testing this behavior the 
>  > likelyhood of unintentional breakage is lessened (of course the MI 
>  > interface will evolve, but the evolution can be managed).
> 
> Yes. I follow this.
> 
>  > > Conversely, in both cases, GDB commands entered through the GUD buffer do not
>  > > currently generate `*stopped' and source display is not updated.
>  > > 
>  > > QUESTION: Is it possible to modify GDB so that it does generate `*stopped' in
>  > > these cases?
>  > > 
>  > > The first case would require that a cli command generates out of bound
>  > > records. This would require a change in behaviour in gdb so need its own flag
>  > > e.g gdb -emacs
>  > > 
>  > > The second case would require that "-interpreter-exec console cli-command"
>  > > generates out of bound records. This could be its defined behaviour as it
>  > > probably would be appropriate to others.
>  > 
>  > You mean something like:
>  > 
>  > -interpreter-exec console break foo
>  > ~Breakpoint 1 created.
>  > =breakpoint-create,breakpoint={nr=5,location=foo,file=bar.c,line=47}
> 
> I was thinking explicitly of *stopped. I haven't found a need for the others
> yet.

To clarify something about level 2 annotations, what exactly is this new 
emacs code dependant on?  For level two annotations the rough equivalent 
to the above is (ignore the yy):

> info break
> 
> yypost-prompt-for-continue
> yyarg-value *
> 0x2000000
> yyarg-end
> , 
> yyarg-begin
> envp
> yyarg-name-end
> =
> yyarg-value *
> 0x20007c4
> yyarg-end
> )
> yyframe-source-begin
>  at 
> yyframe-source-file
> /home/scratch/GDB/src/gdb/testsuite/gdb.base/break.c
> yyframe-source-file-end
> :
> yyframe-source-line
> 75
> yyframe-source-end

and it is these markups that GDB wants to get away from.  They are what 
is littered through out GDB's code and the motivator behind getting rid 
of level two annotations.

>  > That is the second change sitting on the interpreters branch.  
> 
> I've checked out interps-20030202-branch. This doesn't seem to do the above.
> Should I have a different version? Does it generate the *stopped record in
> the manner that I would like? Does it work with interpreter mi mi-command
> also?

Hmm, so to split this into two problems.  How much of each of:

- markups, as in the above marking up of the breakpoint out
- events, as in things like `*stopped'

is this code dependant on?

>  > I don't think it is immediatly necessary though as the imediate objective
>  > is to just address the problem of level two annotations littered through
>  > out things like the breakpoint code.
> 
> I don't follow. Aren't they interconnected? I thought the idea was that the
> quicker that MI got adopted the quicker level two annotations could be dropped

The concern is with the marking up of things like breakpoint output. 
Event notification, I believe, is less of a problem.

Andrew

Re: GDB/MI revisited

[Nick Roberts]

 
 > > I would prefer this approach too since the GUD buffer would then allow
 > > completion. However, without level 2 annotations, the CLI is useless to the
 > > lisp package that I have written, so I don't see how an incremental migration
 > > is possible.
 > 
 > Why exactly is it useless?  Using both [deprecated] level 2 annotations 
 > and "interpreter mi ..." simultaneously.

Ah! I follow you now. Does this mean that you would like to incrementally
obsolete annotations? This relates to something that I said earlier:

NR> Also gdb-ui.el probably doesn't need all the annotations. If you lost some
NR> key ones (frames-invalid and breakpoints-invalid, for example) would this
NR> make it easier to maintain?

I will give incremental migration some thought but unless the benefits are
clear (for you or me) I think it might be easier to do in one go.

 > >  > You could even continue to use "run".
 > > 
 > > Except that the manual says:
 > > 
 > >    This mechanism is provided as an aid to developers of GDB/MI clients
 > > and not as a reliable interface into the CLI.  Since the command is
 > > being interpreteted in an environment that assumes GDB/MI behaviour,
 > > the exact output of such commands is likely to end up being an
 > > un-supported hybrid of GDB/MI and CLI output.
 > > 
 > > Also "run" generates ^done rather than *stopped and I am trying to use the
 > > latter to update the source file display.
 > 
 > The manual is refering to this behavior:
 > 
 > (gdb)
 > target sim
 > &"target sim\n"
 > ~"Connected to the simulator.\n"
 > ^done
 > (gdb)
 > 
 > The new behavior vis:
 > 
 > (gdb)
 > -interpreter-exec console "target sim"
 > ~"Connected to the simulator.\n"
 > ^done
 > (gdb)
 >
 > is documented and supported.

OK, but `-interpreter-exec console' run still generates ^done rather than
*stopped so I would need to recognise this.

 > >  > You mean something like:
 > >  > 
 > >  > -interpreter-exec console break foo
 > >  > ~Breakpoint 1 created.
 > >  > =breakpoint-create,breakpoint={nr=5,location=foo,file=bar.c,line=47}
 > > 
 > > I was thinking explicitly of *stopped. I haven't found a need for the others
 > > yet.
 > 
 > To clarify something about level 2 annotations, what exactly is this new 
 > emacs code dependant on?  For level two annotations the rough equivalent 
 > to the above is (ignore the yy):
 > 
 > > info break
 > > 
 > > yypost-prompt-for-continue
 > > yyarg-value *
 > > 0x2000000
 > > yyarg-end
 ...

How is info break roughly equivalent to break foo?

 > and it is these markups that GDB wants to get away from.  They are what 
 > is littered through out GDB's code and the motivator behind getting rid 
 > of level two annotations.
 
Yes.  I follow this.

 > >  > That is the second change sitting on the interpreters branch.  
 > > 
 > > I've checked out interps-20030202-branch. This doesn't seem to do the above.
 > > Should I have a different version? Does it generate the *stopped record in
 > > the manner that I would like? Does it work with interpreter mi mi-command
 > > also?
 > 
 > Hmm, so to split this into two problems.  How much of each of:
 > 
 > - markups, as in the above marking up of the breakpoint out
 > - events, as in things like `*stopped'
 > 
 > is this code dependant on?

The current code (gdb-ui.el) is completely dependent on the markups that
annotations provides. I want the new code to use `*stopped' to update file
display. If this works as I would like (as described above and previously)
then together with the `^done' record it should provide most of the
functionality that Emacs needs.

 > >  > I don't think it is immediatly necessary though as the imediate objective
 > >  > is to just address the problem of level two annotations littered through
 > >  > out things like the breakpoint code.
 > > 
 > > I don't follow. Aren't they interconnected? I thought the idea was that the
 > > quicker that MI got adopted the quicker level two annotations could be dropped
 > 
 > The concern is with the marking up of things like breakpoint output. 
 > Event notification, I believe, is less of a problem.

If this is the case, I *think* I could modify gdb-ui.el not to use the
annotation breakpoints-invalid quite easily. I don't know what other users
of level 2 annotations, e.g the authors of cgdb, would think, though.

Nick

Re: GDB/MI revisited

[Bob Rossi]

On Sun, Mar 02, 2003 at 11:53:30PM +0000, Nick Roberts wrote:
>  
>  > > I would prefer this approach too since the GUD buffer would then allow
>  > > completion. However, without level 2 annotations, the CLI is useless to the
>  > > lisp package that I have written, so I don't see how an incremental migration
>  > > is possible.
>  > 
>  > Why exactly is it useless?  Using both [deprecated] level 2 annotations 
>  > and "interpreter mi ..." simultaneously.
> 
> Ah! I follow you now. Does this mean that you would like to incrementally
> obsolete annotations? This relates to something that I said earlier:
> 
> NR> Also gdb-ui.el probably doesn't need all the annotations. If you lost some
> NR> key ones (frames-invalid and breakpoints-invalid, for example) would this
> NR> make it easier to maintain?
> 
> I will give incremental migration some thought but unless the benefits are
> clear (for you or me) I think it might be easier to do in one go.
> 
>  > >  > You could even continue to use "run".
>  > > 
>  > > Except that the manual says:
>  > > 
>  > >    This mechanism is provided as an aid to developers of GDB/MI clients
>  > > and not as a reliable interface into the CLI.  Since the command is
>  > > being interpreteted in an environment that assumes GDB/MI behaviour,
>  > > the exact output of such commands is likely to end up being an
>  > > un-supported hybrid of GDB/MI and CLI output.
>  > > 
>  > > Also "run" generates ^done rather than *stopped and I am trying to use the
>  > > latter to update the source file display.
>  > 
>  > The manual is refering to this behavior:
>  > 
>  > (gdb)
>  > target sim
>  > &"target sim\n"
>  > ~"Connected to the simulator.\n"
>  > ^done
>  > (gdb)
>  > 
>  > The new behavior vis:
>  > 
>  > (gdb)
>  > -interpreter-exec console "target sim"
>  > ~"Connected to the simulator.\n"
>  > ^done
>  > (gdb)
>  >
>  > is documented and supported.
> 
> OK, but `-interpreter-exec console' run still generates ^done rather than
> *stopped so I would need to recognise this.
> 
>  > >  > You mean something like:
>  > >  > 
>  > >  > -interpreter-exec console break foo
>  > >  > ~Breakpoint 1 created.
>  > >  > =breakpoint-create,breakpoint={nr=5,location=foo,file=bar.c,line=47}
>  > > 
>  > > I was thinking explicitly of *stopped. I haven't found a need for the others
>  > > yet.
>  > 
>  > To clarify something about level 2 annotations, what exactly is this new 
>  > emacs code dependant on?  For level two annotations the rough equivalent 
>  > to the above is (ignore the yy):
>  > 
>  > > info break
>  > > 
>  > > yypost-prompt-for-continue
>  > > yyarg-value *
>  > > 0x2000000
>  > > yyarg-end
>  ...
> 
> How is info break roughly equivalent to break foo?
> 
>  > and it is these markups that GDB wants to get away from.  They are what 
>  > is littered through out GDB's code and the motivator behind getting rid 
>  > of level two annotations.
>  
> Yes.  I follow this.
> 
>  > >  > That is the second change sitting on the interpreters branch.  
>  > > 
>  > > I've checked out interps-20030202-branch. This doesn't seem to do the above.
>  > > Should I have a different version? Does it generate the *stopped record in
>  > > the manner that I would like? Does it work with interpreter mi mi-command
>  > > also?
>  > 
>  > Hmm, so to split this into two problems.  How much of each of:
>  > 
>  > - markups, as in the above marking up of the breakpoint out
>  > - events, as in things like `*stopped'
>  > 
>  > is this code dependant on?
> 
> The current code (gdb-ui.el) is completely dependent on the markups that
> annotations provides. I want the new code to use `*stopped' to update file
> display. If this works as I would like (as described above and previously)
> then together with the `^done' record it should provide most of the
> functionality that Emacs needs.
> 
>  > >  > I don't think it is immediatly necessary though as the imediate objective
>  > >  > is to just address the problem of level two annotations littered through
>  > >  > out things like the breakpoint code.
>  > > 
>  > > I don't follow. Aren't they interconnected? I thought the idea was that the
>  > > quicker that MI got adopted the quicker level two annotations could be dropped
>  > 
>  > The concern is with the marking up of things like breakpoint output. 
>  > Event notification, I believe, is less of a problem.
> 
> If this is the case, I *think* I could modify gdb-ui.el not to use the
> annotation breakpoints-invalid quite easily. I don't know what other users
> of level 2 annotations, e.g the authors of cgdb, would think, though.

cgdb doesn't depend on breakpoints-invalid because they were unreliable
in some versions of gdb. For example, when the user deleted the last
breakpoint, the 'breakpoints-invalid' wouldn't be triggered. So, cgdb
requests the breakpoints after every user command.

It would be great if in MI, the client could ask for notifications that
it is interested in ( breakpoints, source file and line, variables ... )

Bob Rossi

Re: GDB/MI revisited

[Andrew Cagney]

>  
>  > > I would prefer this approach too since the GUD buffer would then allow
>  > > completion. However, without level 2 annotations, the CLI is useless to the
>  > > lisp package that I have written, so I don't see how an incremental migration
>  > > is possible.
>  > 
>  > Why exactly is it useless?  Using both [deprecated] level 2 annotations 
>  > and "interpreter mi ..." simultaneously.
> 
> Ah! I follow you now. Does this mean that you would like to incrementally
> obsolete annotations? This relates to something that I said earlier:

There is always room for both compromize and reality :-)

> If this is the case, I *think* I could modify gdb-ui.el not to use the
> annotation breakpoints-invalid quite easily. I don't know what other users
> of level 2 annotations, e.g the authors of cgdb, would think, though.

What about defining `level three' annotations as the event stuff from 
level two but with all the breakpoint et.al. markups removed?

Having the CLI generate event annotations is hardly different to having 
MI generate it's event messages.

Andrew

Re: GDB/MI revisited

[Nick Roberts]

 > What about defining `level three' annotations as the event stuff from 
 > level two but with all the breakpoint et.al. markups removed?
 
I think this is a good idea if it doesn't mean too much extra work for you.
It would certainly create some breathing space. Perhaps you could be more
specific about al if you are planning to remove other annotations than
breakpoints-invalid e.g frames-invalid.

 > Having the CLI generate event annotations is hardly different to having 
 > MI generate it's event messages.

Which annotations constitute the event annotations?

Nick

Re: GDB/MI revisited

[Andrew Cagney]

>  > What about defining `level three' annotations as the event stuff from 
>  > level two but with all the breakpoint et.al. markups removed?
>  
> I think this is a good idea if it doesn't mean too much extra work for you.
> It would certainly create some breathing space. Perhaps you could be more
> specific about al if you are planning to remove other annotations than
> breakpoints-invalid e.g frames-invalid.
> 
>  > Having the CLI generate event annotations is hardly different to having 
>  > MI generate it's event messages.
> 
> Which annotations constitute the event annotations?

Things that look/sound like:
	breakpoints-changed
	stopped
	running
	...
Andrew