On Friday 02 May 2008 19:57:19 Daniel Jacobowitz wrote:
> On Thu, May 01, 2008 at 04:35:52PM +0300, Vladimir Prus wrote:
> > This has no regressions in default and async modes on x86. OK?
> 
> Just minor concerns.  Docs - yes, I know very well that you know this
> - but making sure we see docs before the code change goes in makes
> sure that no one forgets in the crush of other patches.  So, sorry,
> but expect to keep getting this reply :-)

I've added the docs. Eli, are those OK?

> Also, what are the expected changes in async and non-async?  Will we
> start generating this for non-async and is that likely to break any
> frontend?

The expected change than any command that resumes a target will produce
*running, in either all-stop or non-stop mode. I don't expect this
to break any frontend, as frontends are supposed to ignore things
they don't understand.

> 
> > 	* doc/observer.texi (target_resumed): New observer.
> 
> Doc has its own changelog.
> 
> > diff --git a/gdb/testsuite/gdb.mi/mi-break.exp b/gdb/testsuite/gdb.mi/mi-break.exp
> > index 48527fd..b895020 100644
> > --- a/gdb/testsuite/gdb.mi/mi-break.exp
> > +++ b/gdb/testsuite/gdb.mi/mi-break.exp
> > @@ -174,11 +174,11 @@ proc test_error {} {
> >      # containing function call, the internal breakpoint created to handle
> >      # function call would be reported, messing up MI output.
> >      mi_gdb_test "-var-create V * return_1()" \
> > -        "\\^done,name=\"V\",numchild=\"0\",value=\"1\",type=\"int\"" \
> > +        ".*\\^done,name=\"V\",numchild=\"0\",value=\"1\",type=\"int\"" \
> >          "create varobj for function call"
> 
> The comment suggests this test is supposed to fail if there is stray
> output... adding a leading .* is not nice.

Right. In fact, this test no longer has to be changed.

Here's a revised patch, OK?

- Volodya