[RFC/MI] Event Records vs Commands

[RFC/MI] Event Records vs Commands

[Keith Seitz]

Hi,

This is the promised gdbmi.texinfo proposal that I referred to in:

http://sources.redhat.com/ml/gdb/2002-06/msg00106.html

This patch formalizes events in MI. Specifically, I propose to whack
notify-async-output from aync-record and add event-record to
out-of-band-record.

I've modified all the breakpoint command examples to reflect the fact that
breakpoint commands will no longer print information about the breakpoint.
Instead this information is retrieved from the event. For example:

- old way
(gdb)
-break-insert main
^done,bkpt={number="1",addr="0xdeadbeef",file="main.c",line="5"}
(gdb)

- new way
(gdb)
-break-insert main
=breakpoint-create,number="1"
(gdb)
-break-info 1
^done,BreakpointTable={...}

I have completed the changes to MI to accomplish this, and I will submit
these patches once this is all approved. I plan to check this all into my
interpreter branch (kseitz_interps-20020528-branch) until everything
is finalized. I will then migrate the whole (approved) thing into cvs
head.

Comments?
Keith

ChangeLog
2002-06-13  Keith Seitz  <keiths@redhat.com>

	* gdbmi.texinfo: Add event-record output syntax.
	Remove notify-async-output.
	Update all examples to show breakpoint events and
	remove redundant breakpoint info on "-break-insert". The event
	now supplies everything that is needed.

Patch
Index: gdbmi.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/mi/gdbmi.texinfo,v
retrieving revision 1.26
diff -p -r1.26 gdbmi.texinfo
*** gdbmi.texinfo	25 Feb 2002 02:13:09 -0000	1.26
--- gdbmi.texinfo	14 Jun 2002 05:06:28 -0000
*************** corresponding output for that command wi
*** 224,233 ****
  @code{ [ @var{token} ] "^" @var{result-class} ( "," @var{result} )* @var{nl}}

  @item @var{out-of-band-record} @expansion{}
! @code{@var{async-record} | @var{stream-record}}

  @item @var{async-record} @expansion{}
! @code{@var{exec-async-output} | @var{status-async-output} | @var{notify-async-output}}

  @item @var{exec-async-output} @expansion{}
  @code{[ @var{token} ] "*" @var{async-output}}
--- 224,233 ----
  @code{ [ @var{token} ] "^" @var{result-class} ( "," @var{result} )* @var{nl}}

  @item @var{out-of-band-record} @expansion{}
! @code{@var{async-record} | @var{stream-record}} | @var{event-record}

  @item @var{async-record} @expansion{}
! @code{@var{exec-async-output} | @var{status-async-output}}

  @item @var{exec-async-output} @expansion{}
  @code{[ @var{token} ] "*" @var{async-output}}
*************** corresponding output for that command wi
*** 235,243 ****
  @item @var{status-async-output} @expansion{}
  @code{[ @var{token} ] "+" @var{async-output}}

- @item @var{notify-async-output} @expansion{}
- @code{[ @var{token} ] "=" @var{async-output}}
-
  @item @var{async-output} @expansion{}
  @code{@var{async-class} ( "," @var{result} )* @var{nl}}

--- 235,240 ----
*************** depending on the needs---this is still i
*** 279,284 ****
--- 276,291 ----
  @item @var{log-stream-output} @expansion{}
  @code{"&" @var{c-string}}

+ @item @var{event-record} @expansion{}
+ @code{"=" @var{event}}
+
+ @item @var{event} @expansion{}
+ @code{@var{event-class} ( "," @var{value} )*}
+
+ @item @var{event-class} @expansion{}
+ @xref{GDB/MI Event Records, , @sc{gdb/mi} Event Records}, for a list of
+ supported events.
+
  @item @var{nl} @expansion{}
  @code{CR | CR-LF}

*************** prefixed by @samp{+}.
*** 312,321 ****
  @samp{*}.

  @item
! @cindex notify output in @sc{gdb/mi}
! @var{notify-async-output} contains supplementary information that the
! client should handle (e.g., a new breakpoint information).  All notify
! output is prefixed by @samp{=}.

  @item
  @cindex console output in @sc{gdb/mi}
--- 319,328 ----
  @samp{*}.

  @item
! @cindex events in @sc{gdb/mi}
! @var{event-record} contains supplementary information that the
! client should handle (e.g., a new breakpoint was inserted).  All events
! are prefixed by @samp{=}.

  @item
  @cindex console output in @sc{gdb/mi}
*************** Here's an example of a simple CLI comman
*** 386,392 ****

  @example
  -> -symbol-file xyz.exe
! <- *breakpoint,nr="3",address="0x123",source="a.c:123"
  <- (@value{GDBP})
  @end example

--- 395,402 ----

  @example
  -> -symbol-file xyz.exe
! <- =breakpoint-create,number="3"
! <- ^done
  <- (@value{GDBP})
  @end example

*************** an un-supported hybrid of @sc{gdb/mi} an
*** 425,430 ****
--- 435,441 ----
  * GDB/MI Result Records::
  * GDB/MI Stream Records::
  * GDB/MI Out-of-band Records::
+ * GDB/MI Event Records::
  @end menu

  @node GDB/MI Result Records
*************** additional changes that have occurred.
*** 492,501 ****
  consequence of @sc{gdb/mi} (e.g., a breakpoint modified) or a result of
  target activity (e.g., target stopped).

! The following is a preliminary list of possible out-of-band records.

  @table @code
! @item "*" "stop"
  @end table


--- 503,544 ----
  consequence of @sc{gdb/mi} (e.g., a breakpoint modified) or a result of
  target activity (e.g., target stopped).

! @node GDB/MI Event Records
! @subsection @sc{gdb/mi} Event Records
!
! @cindex event records in @sc{gdb/mi}
! @cindex @sc{gdb/mi}, event records
! @dfn{Event records} are used to notify the @sc{gdb/mi} client of any
! debugger state changes which may occur as a result of commands executed
! in @value{GDBN}. Events can be generated by any command, whether that command
! was executed in the @sc{gdb/mi} interpreter or the console interpreter.
!
! The following is a preliminary list of event records.

  @table @code
! @item stop
! The inferior stopped.
! @c Need an example!
!
! @item breakpoint-create
! @item breakpoint-modify
! @item breakpoint-delete
! @item tracepoint-create
! @item tracepoint-modify
! @item tracepoint-delete
! A breakpoint or tracepoint was created, modified, or deleted. In all cases,
! the event will also report the @code{number} of the affected breakpoint/tracepoint:
! @example
! =breakpoint-create,number="1"
! @end example
!
! @item architecture-changed
! This event indicates that @value{GDBN} has changed architectures, and that
! the user interface may need to update certain views that are architecture-dependent,
! such as registers.
! @example
! =architecture-changed
! @end example
  @end table


*************** The corresponding @value{GDBN} command i
*** 574,583 ****
  @smallexample
  (@value{GDBP})
  -break-insert main
! ^done,bkpt=@{number="1",addr="0x000100d0",file="hello.c",line="5"@}
  (@value{GDBP})
  -break-after 1 3
! ~
  ^done
  (@value{GDBP})
  -break-list
--- 617,627 ----
  @smallexample
  (@value{GDBP})
  -break-insert main
! =breakpoint-create,number="1"
! ^done
  (@value{GDBP})
  -break-after 1 3
! =breakpoint-modify,number="1"
  ^done
  (@value{GDBP})
  -break-list
*************** The corresponding @value{GDBN} command i
*** 626,631 ****
--- 670,676 ----
  @smallexample
  (@value{GDBP})
  -break-condition 1 1
+ =breakpoint-modify,number="1"
  ^done
  (@value{GDBP})
  -break-list
*************** The corresponding @value{GDBN} command i
*** 663,668 ****
--- 708,714 ----
  @example
  (@value{GDBP})
  -break-delete 1
+ =breakpoint-delete,number="1"
  ^done
  (@value{GDBP})
  -break-list
*************** The corresponding @value{GDBN} command i
*** 698,703 ****
--- 744,750 ----
  @smallexample
  (@value{GDBP})
  -break-disable 2
+ =breakpoint-modify,number="2"
  ^done
  (@value{GDBP})
  -break-list
*************** The corresponding @value{GDBN} command i
*** 733,738 ****
--- 780,786 ----
  @smallexample
  (@value{GDBP})
  -break-enable 2
+ =breakpoint-modify,number="2"
  ^done
  (@value{GDBP})
  -break-list
*************** given regular expression.  Other flags a
*** 808,831 ****
  expresson.
  @end table

- @subsubheading Result
-
- The result is in the form:
-
- @example
-  ^done,bkptno="@var{number}",func="@var{funcname}",
-   file="@var{filename}",line="@var{lineno}"
- @end example
-
- @noindent
- where @var{number} is the @value{GDBN} number for this breakpoint, @var{funcname}
- is the name of the function where the breakpoint was inserted,
- @var{filename} is the name of the source file which contains this
- function, and @var{lineno} is the source line number within that file.
-
- Note: this format is open to change.
- @c An out-of-band breakpoint instead of part of the result?
-
  @subsubheading @value{GDBN} Command

  The corresponding @value{GDBN} commands are @samp{break}, @samp{tbreak},
--- 856,861 ----
*************** The corresponding @value{GDBN} commands
*** 836,845 ****
  @smallexample
  (@value{GDBP})
  -break-insert main
! ^done,bkpt=@{number="1",addr="0x0001072c",file="recursive2.c",line="4"@}
  (@value{GDBP})
  -break-insert -t foo
! ^done,bkpt=@{number="2",addr="0x00010774",file="recursive2.c",line="11"@}
  (@value{GDBP})
  -break-list
  ^done,BreakpointTable=@{nr_rows="2",nr_cols="6",
--- 866,877 ----
  @smallexample
  (@value{GDBP})
  -break-insert main
! =breakpoint-create,number="1"
! ^done
  (@value{GDBP})
  -break-insert -t foo
! =breakpoint-create,number="2"
! ^done
  (@value{GDBP})
  -break-list
  ^done,BreakpointTable=@{nr_rows="2",nr_cols="6",
*************** addr="0x00010774",func="foo",file="recur
*** 856,862 ****
  (@value{GDBP})
  -break-insert -r foo.*
  ~int foo(int, int);
! ^done,bkpt=@{number="3",addr="0x00010774",file="recursive2.c",line="11"@}
  (@value{GDBP})
  @end smallexample

--- 888,895 ----
  (@value{GDBP})
  -break-insert -r foo.*
  ~int foo(int, int);
! =breakpoint-create,number="1"
! ^done
  (@value{GDBP})
  @end smallexample

*************** Setting a watchpoint on a variable in th
*** 965,971 ****
  @smallexample
  (@value{GDBP})
  -break-watch x
! ^done,wpt=@{number="2",exp="x"@}
  (@value{GDBP})
  -exec-continue
  ^running
--- 998,1005 ----
  @smallexample
  (@value{GDBP})
  -break-watch x
! =breakpoint-create,number="2"
! ^done
  (@value{GDBP})
  -exec-continue
  ^running
*************** for the watchpoint going out of scope.
*** 982,988 ****
  @smallexample
  (@value{GDBP})
  -break-watch C
! ^done,wpt=@{number="5",exp="C"@}
  (@value{GDBP})
  -exec-continue
  ^running
--- 1016,1023 ----
  @smallexample
  (@value{GDBP})
  -break-watch C
! =breakpoint-create,number="5"
! ^done
  (@value{GDBP})
  -exec-continue
  ^running
*************** deleted.
*** 1007,1013 ****
  @smallexample
  (@value{GDBP})
  -break-watch C
! ^done,wpt=@{number="2",exp="C"@}
  (@value{GDBP})
  -break-list
  ^done,BreakpointTable=@{nr_rows="2",nr_cols="6",
--- 1042,1049 ----
  @smallexample
  (@value{GDBP})
  -break-watch C
! =breakpoint-create,number="2"
! ^done
  (@value{GDBP})
  -break-list
  ^done,BreakpointTable=@{nr_rows="2",nr_cols="6",

Re: [RFC/MI] Event Records vs Commands

[Eli Zaretskii]

> Date: Thu, 13 Jun 2002 22:24:36 -0700 (PDT)
> From: Keith Seitz <keiths@redhat.com>
> 
> This is the promised gdbmi.texinfo proposal that I referred to in:
> 
> http://sources.redhat.com/ml/gdb/2002-06/msg00106.html
> 
> This patch formalizes events in MI. Specifically, I propose to whack
> notify-async-output from aync-record and add event-record to
> out-of-band-record.

Thanks.  This is approved, but please take care of teh following
small problems:

> ! in @value{GDBN}. Events can be generated by any command, whether that command

Please always leave two spaces after a period that ends a sentence.
This is important for the printed version to be typeset correctly by
TeX.

> ! @item breakpoint-create
> ! @item breakpoint-modify
> ! @item breakpoint-delete
> ! @item tracepoint-create
> ! @item tracepoint-modify
> ! @item tracepoint-delete
> ! A breakpoint or tracepoint was created, modified, or deleted. In all cases,

You cannot lump several @item's together, the result will look badly.
All the @item's but the first need to be an @itemx instead.

> ! @example
> ! =breakpoint-create,number="1"
> ! @end example

I believe the general policy in the GDB manual is to use @smallexample
throughout.

Re: [RFC/MI] Event Records vs Commands

[Andreas Schwab]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

|> Thanks.  This is approved, but please take care of teh following
|> small problems:
|> 
|> > ! in @value{GDBN}. Events can be generated by any command, whether that command
|> 
|> Please always leave two spaces after a period that ends a sentence.
|> This is important for the printed version to be typeset correctly by
|> TeX.

Actually TeX doesn't care about the extra whitespace, it treats them all
the same.  The real problem is that @value{GDBN} expands to an all-caps
text, which causes TeX to not consider the period to be a sentence end.
All occurences of periods after @value{GDBN} should be replaced by `@.' to
fix this.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [RFC/MI] Event Records vs Commands

[Andrew Cagney]

> Hi,
> 
> This is the promised gdbmi.texinfo proposal that I referred to in:
> 
> http://sources.redhat.com/ml/gdb/2002-06/msg00106.html
> 
> This patch formalizes events in MI. Specifically, I propose to whack
> notify-async-output from aync-record and add event-record to
> out-of-band-record.

Breakpoint events can occure ``asynchronously'':  a shared library load 
might trigger the setting of a breakpoint;  a user's breakpoint commands 
might change the state of a breakpoint and then continue.

Hence, as far as I can tell you just want to ``notify-async-output''.

> I've modified all the breakpoint command examples to reflect the fact that
> breakpoint commands will no longer print information about the breakpoint.
> Instead this information is retrieved from the event. For example:
> 
> - old way
> (gdb)
> -break-insert main
> ^done,bkpt={number="1",addr="0xdeadbeef",file="main.c",line="5"}
> (gdb)
> 
> - new way
> (gdb)
> -break-insert main
> =breakpoint-create,number="1"
> (gdb)

I believe this is wrong.  There should still be a ``^done''.

 > -break-info 1
 > ^done,BreakpointTable={...}


> I have completed the changes to MI to accomplish this, and I will submit
> these patches once this is all approved. I plan to check this all into my
> interpreter branch (kseitz_interps-20020528-branch) until everything
> is finalized. I will then migrate the whole (approved) thing into cvs
> head.

Keep in mind that the examples are lifted from the testsuite.

Given breakpoint output appears everywhere in the testsuite, the import 
is going to be a little large.  There should still be a few things that 
can be cherry picked though - some of the testsuite shuffle for instance.

>   @example
>   -> -symbol-file xyz.exe
> ! <- *breakpoint,nr="3",address="0x123",source="a.c:123"
>   <- (@value{GDBP})
>   @end example
> 
> --- 395,402 ----
> 
>   @example
>   -> -symbol-file xyz.exe
> ! <- =breakpoint-create,number="3"
> ! <- ^done
>   <- (@value{GDBP})
>   @end example

If breakpoint-create included complete breakpoint information an 
additional roundtrip could be avoided.  Is this significant?  I suspect 
this is a question for some of the apple hackers as they would have a 
better feel for how critical this one is :-)

Andrew

Re: [RFC/MI] Event Records vs Commands

[Andrew Cagney]

> Hence, as far as I can tell you just want to ``notify-async-output''.


Try:

...want to document ``notify-async-output'' or (less likely?) replace it 
with ``event-async-output''.

Async output is anything that isn't bound to ``^done'' et.al.

Andrew

Re: [RFC/MI] Event Records vs Commands

[Keith Seitz]

On Sat, 15 Jun 2002, Andrew Cagney wrote:

> Try:
>
> ...want to document ``notify-async-output'' or (less likely?) replace it
> with ``event-async-output''.

This is the approach I've taken with my next attempt (which also includes
the fixes recommended by Eli, following the convention with two spaces
after @value{GDBN} -- if people want me to switch them all to use @., I
can submit separate patch for that).

> Async output is anything that isn't bound to ``^done'' et.al. >

But it seems to be bound to the prompt. Apple has changed their version so
that it is NOT bound to the prompt. We'll need to discuss this sometime
later.

Next round of comments, please.
Keith

Index: mi/gdbmi.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/mi/gdbmi.texinfo,v
retrieving revision 1.26
diff -p -r1.26 gdbmi.texinfo
*** mi/gdbmi.texinfo	25 Feb 2002 02:13:09 -0000	1.26
--- mi/gdbmi.texinfo	18 Jun 2002 18:26:24 -0000
*************** prefixed by @samp{+}.
*** 313,321 ****

  @item
  @cindex notify output in @sc{gdb/mi}
! @var{notify-async-output} contains supplementary information that the
! client should handle (e.g., a new breakpoint information).  All notify
! output is prefixed by @samp{=}.

  @item
  @cindex console output in @sc{gdb/mi}
--- 313,321 ----

  @item
  @cindex notify output in @sc{gdb/mi}
! @var{notify-async-output} contains supplementary information (events) that the
! client should handle (e.g., a new breakpoint was inserted).  All notify
! are prefixed by @samp{=}.

  @item
  @cindex console output in @sc{gdb/mi}
*************** Here's an example of a simple CLI comman
*** 386,392 ****

  @example
  -> -symbol-file xyz.exe
! <- *breakpoint,nr="3",address="0x123",source="a.c:123"
  <- (@value{GDBP})
  @end example

--- 388,395 ----

  @example
  -> -symbol-file xyz.exe
! <- =breakpoint-create,number="3"
! <- ^done
  <- (@value{GDBP})
  @end example

*************** additional changes that have occurred.
*** 492,501 ****
  consequence of @sc{gdb/mi} (e.g., a breakpoint modified) or a result of
  target activity (e.g., target stopped).

! The following is a preliminary list of possible out-of-band records.

  @table @code
! @item "*" "stop"
  @end table


--- 495,526 ----
  consequence of @sc{gdb/mi} (e.g., a breakpoint modified) or a result of
  target activity (e.g., target stopped).

! The following is a preliminary list of out-of-band records.

  @table @code
! @item stop
! The inferior stopped.
! @c Need an example!
!
! @item breakpoint-create
! @itemx breakpoint-modify
! @itemx breakpoint-delete
! @itemx tracepoint-create
! @itemx tracepoint-modify
! @itemx tracepoint-delete
! A breakpoint or tracepoint was created, modified, or deleted. In all cases,
! the event will also report the @code{number} of the affected breakpoint/tracepoint:
! @smallexample
! =breakpoint-create,number="1"
! @end smallexample
!
! @item architecture-changed
! This event indicates that @value{GDBN} has changed architectures, and that
! the user interface may need to update certain views that are architecture-dependent,
! such as registers.
! @smallexample
! =architecture-changed
! @end smallexample
  @end table


*************** The corresponding @value{GDBN} command i
*** 574,583 ****
  @smallexample
  (@value{GDBP})
  -break-insert main
! ^done,bkpt=@{number="1",addr="0x000100d0",file="hello.c",line="5"@}
  (@value{GDBP})
  -break-after 1 3
! ~
  ^done
  (@value{GDBP})
  -break-list
--- 599,609 ----
  @smallexample
  (@value{GDBP})
  -break-insert main
! =breakpoint-create,number="1"
! ^done
  (@value{GDBP})
  -break-after 1 3
! =breakpoint-modify,number="1"
  ^done
  (@value{GDBP})
  -break-list
*************** The corresponding @value{GDBN} command i
*** 626,631 ****
--- 652,658 ----
  @smallexample
  (@value{GDBP})
  -break-condition 1 1
+ =breakpoint-modify,number="1"
  ^done
  (@value{GDBP})
  -break-list
*************** The corresponding @value{GDBN} command i
*** 663,668 ****
--- 690,696 ----
  @example
  (@value{GDBP})
  -break-delete 1
+ =breakpoint-delete,number="1"
  ^done
  (@value{GDBP})
  -break-list
*************** The corresponding @value{GDBN} command i
*** 698,703 ****
--- 726,732 ----
  @smallexample
  (@value{GDBP})
  -break-disable 2
+ =breakpoint-modify,number="2"
  ^done
  (@value{GDBP})
  -break-list
*************** The corresponding @value{GDBN} command i
*** 733,738 ****
--- 762,768 ----
  @smallexample
  (@value{GDBP})
  -break-enable 2
+ =breakpoint-modify,number="2"
  ^done
  (@value{GDBP})
  -break-list
*************** given regular expression.  Other flags a
*** 808,831 ****
  expresson.
  @end table

- @subsubheading Result
-
- The result is in the form:
-
- @example
-  ^done,bkptno="@var{number}",func="@var{funcname}",
-   file="@var{filename}",line="@var{lineno}"
- @end example
-
- @noindent
- where @var{number} is the @value{GDBN} number for this breakpoint, @var{funcname}
- is the name of the function where the breakpoint was inserted,
- @var{filename} is the name of the source file which contains this
- function, and @var{lineno} is the source line number within that file.
-
- Note: this format is open to change.
- @c An out-of-band breakpoint instead of part of the result?
-
  @subsubheading @value{GDBN} Command

  The corresponding @value{GDBN} commands are @samp{break}, @samp{tbreak},
--- 838,843 ----
*************** The corresponding @value{GDBN} commands
*** 836,845 ****
  @smallexample
  (@value{GDBP})
  -break-insert main
! ^done,bkpt=@{number="1",addr="0x0001072c",file="recursive2.c",line="4"@}
  (@value{GDBP})
  -break-insert -t foo
! ^done,bkpt=@{number="2",addr="0x00010774",file="recursive2.c",line="11"@}
  (@value{GDBP})
  -break-list
  ^done,BreakpointTable=@{nr_rows="2",nr_cols="6",
--- 848,859 ----
  @smallexample
  (@value{GDBP})
  -break-insert main
! =breakpoint-create,number="1"
! ^done
  (@value{GDBP})
  -break-insert -t foo
! =breakpoint-create,number="2"
! ^done
  (@value{GDBP})
  -break-list
  ^done,BreakpointTable=@{nr_rows="2",nr_cols="6",
*************** addr="0x00010774",func="foo",file="recur
*** 856,862 ****
  (@value{GDBP})
  -break-insert -r foo.*
  ~int foo(int, int);
! ^done,bkpt=@{number="3",addr="0x00010774",file="recursive2.c",line="11"@}
  (@value{GDBP})
  @end smallexample

--- 870,877 ----
  (@value{GDBP})
  -break-insert -r foo.*
  ~int foo(int, int);
! =breakpoint-create,number="1"
! ^done
  (@value{GDBP})
  @end smallexample

*************** Setting a watchpoint on a variable in th
*** 965,971 ****
  @smallexample
  (@value{GDBP})
  -break-watch x
! ^done,wpt=@{number="2",exp="x"@}
  (@value{GDBP})
  -exec-continue
  ^running
--- 980,987 ----
  @smallexample
  (@value{GDBP})
  -break-watch x
! =breakpoint-create,number="2"
! ^done
  (@value{GDBP})
  -exec-continue
  ^running
*************** for the watchpoint going out of scope.
*** 982,988 ****
  @smallexample
  (@value{GDBP})
  -break-watch C
! ^done,wpt=@{number="5",exp="C"@}
  (@value{GDBP})
  -exec-continue
  ^running
--- 998,1005 ----
  @smallexample
  (@value{GDBP})
  -break-watch C
! =breakpoint-create,number="5"
! ^done
  (@value{GDBP})
  -exec-continue
  ^running
*************** deleted.
*** 1007,1013 ****
  @smallexample
  (@value{GDBP})
  -break-watch C
! ^done,wpt=@{number="2",exp="C"@}
  (@value{GDBP})
  -break-list
  ^done,BreakpointTable=@{nr_rows="2",nr_cols="6",
--- 1024,1031 ----
  @smallexample
  (@value{GDBP})
  -break-watch C
! =breakpoint-create,number="2"
! ^done
  (@value{GDBP})
  -break-list
  ^done,BreakpointTable=@{nr_rows="2",nr_cols="6",

Re: [RFC/MI] Event Records vs Commands

[Eli Zaretskii]

> Date: Tue, 18 Jun 2002 11:34:29 -0700 (PDT)
> From: Keith Seitz <keiths@redhat.com>
> 
> This is the approach I've taken with my next attempt (which also includes
> the fixes recommended by Eli, following the convention with two spaces
> after @value{GDBN} -- if people want me to switch them all to use @., I
> can submit separate patch for that).

Thanks, approved.

Re: [RFC/MI] Event Records vs Commands

[Andrew Cagney]

> On Sat, 15 Jun 2002, Andrew Cagney wrote:
> 
> 
>> Try:
>>
>> ...want to document ``notify-async-output'' or (less likely?) replace it
>> with ``event-async-output''.
> 
> 
> This is the approach I've taken with my next attempt (which also includes
> the fixes recommended by Eli, following the convention with two spaces
> after @value{GDBN} -- if people want me to switch them all to use @., I
> can submit separate patch for that).
> 
> 
>> Async output is anything that isn't bound to ``^done'' et.al. >
> 
> 
> But it seems to be bound to the prompt. Apple has changed their version so
> that it is NOT bound to the prompt. We'll need to discuss this sometime
> later.

Ah, dig dig.

The idea was that ``\n(gdb)'' would act as a terminal signal for 
asynchronous events.

That way you would see:

	event message
	event message
	(gdb)

	<time passes>

	event emssage
	(gdb)

	<time passes>

and not:

	event message
	event message

	<time passes>

	event message
	.
	.

however, yes, open to negotiation.

Andrew

Re: [RFC/MI] Event Records vs Commands

[Keith Seitz]

On Sat, 15 Jun 2002, Andrew Cagney wrote:

> Breakpoint events can occure ``asynchronously'':  a shared library load
> might trigger the setting of a breakpoint;  a user's breakpoint commands
> might change the state of a breakpoint and then continue.
>
> Hence, as far as I can tell you just want to ``notify-async-output''.

Ok.

> > (gdb)
> > -break-insert main
> > =breakpoint-create,number="1"
> > (gdb)
>
> I believe this is wrong.  There should still be a ``^done''.

Yes, that was just an omission on my part. The manual still contains the
"^done" bits.

> Given breakpoint output appears everywhere in the testsuite, the import
> is going to be a little large.  There should still be a few things that
> can be cherry picked though - some of the testsuite shuffle for instance.

Yes. I do not plan to dump one mega-patch onto people. I will submit
patches piece by piece as best I can, and there will always be the sandbox
branch that I'm working on in case people want to play with the whole
thing.

> If breakpoint-create included complete breakpoint information an
> additional roundtrip could be avoided.  Is this significant?  I suspect
> this is a question for some of the apple hackers as they would have a
> better feel for how critical this one is :-)

I don't really think a breakpoint query is going to do too much, but if
we want to keep it, we certainly can. All I would need to do is make the
code more event friendly.

Keith

Re: [RFC/MI] Event Records vs Commands

[Andrew Cagney]

>> If breakpoint-create included complete breakpoint information an
>> additional roundtrip could be avoided.  Is this significant?  I suspect
>> this is a question for some of the apple hackers as they would have a
>> better feel for how critical this one is :-)
> 
> 
> I don't really think a breakpoint query is going to do too much, but if
> we want to keep it, we certainly can. All I would need to do is make the
> code more event friendly.

So for the first cut - just return the breakpoint number.
Then, if performance provdes to be a problem, update it to include the 
other info.

Ok.

Andrew