From: Vladimir Prus <vladimir@codesourcery.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] Implement *running.
Date: Tue, 27 May 2008 19:07:00 -0000 [thread overview]
Message-ID: <200805271955.04084.vladimir@codesourcery.com> (raw)
In-Reply-To: <200805041837.44909.vladimir@codesourcery.com>
On Sunday 04 May 2008 18:37:43 Vladimir Prus wrote:
> 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?
Dan,
do you have any further comments on this patch, or it's OK to commit?
- Volodya
next prev parent reply other threads:[~2008-05-27 15:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-01 13:36 Vladimir Prus
2008-05-02 9:57 ` Eli Zaretskii
2008-05-02 15:59 ` Daniel Jacobowitz
2008-05-04 16:33 ` Vladimir Prus
2008-05-04 19:50 ` Eli Zaretskii
2008-05-11 15:32 ` Vladimir Prus
2008-05-11 21:46 ` Eli Zaretskii
2008-05-27 19:07 ` Vladimir Prus [this message]
2008-06-05 15:50 ` Daniel Jacobowitz
2008-06-10 12:43 ` Vladimir Prus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200805271955.04084.vladimir@codesourcery.com \
--to=vladimir@codesourcery.com \
--cc=drow@false.org \
--cc=eliz@gnu.org \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox