Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Luis Machado <lgustavo@codesourcery.com>
To: Tom Tromey <tromey@redhat.com>
Cc: Pedro Alves <palves@redhat.com>,
	 ali_anwar <ali_anwar@codesourcery.com>,
	dje@google.com, Yao Qi <yao@codesourcery.com>,
	 gdb-patches@sourceware.org,
	Vladimir Prus <vladimir@codesourcery.com>
Subject: Re: Patch to propagate GDB's knowledge of the executing state to frontend
Date: Tue, 13 Nov 2012 22:23:00 -0000	[thread overview]
Message-ID: <50A2C88B.6070105@codesourcery.com> (raw)
In-Reply-To: <87wqxp414y.fsf@fleche.redhat.com>

On 11/13/2012 07:57 PM, Tom Tromey wrote:
> Luis>  Should frontends relying on MI information treat ^error specially and
> Luis>  not look for any *stopped records?
>
> I don't know the answer to this.  I did find this though:
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=7778
>
> I tend to think it would be cleanest if gdb were to emit a *stopped in
> case of error -- but only if it previously emitted *running.  I don't
> know how feasible this is.

Right. That seems to be what Ali's patch is attempting to address, in 
order to improve the relationship with the frontends.

>
> Luis>  The MI specification gives room for slightly different interpretations
> Luis>  unfortunately.
>
> For me, the text for "*running" is pretty clear:
>
>       The frontend should assume that no interaction with a
>       running thread is possible after this notification is produced.
>
> I'm curious where the text is that gives room for another approach.

I wanted to know what is to be done once an ^error is thrown at the 
frontend and how it should behave.

There is this text:

"There's no guarantee that whenever an MI command reports an error, gdb 
or the target are in any specific state, and especially, the state is 
not reverted to the state before the MI command was processed. 
Therefore, whenever an MI command results in an error, we recommend that 
the frontend refreshes all the information shown in the user interface."

It is not clear how things need to be refreshed, specially when the 
frontend needs to assume a thread/inferior is still running after it saw 
^running but did not see a *stopped record, though it did see an ^error. 
But ^error does not imply the target has stopped.

So it needs to refresh information, but should it forget the target was 
running and attempt to fetch data anyway or should it do something else?

In the case of all-stop mode, we know the inferior is stopped. This may 
not be true for non-stop though.

Luis


  reply	other threads:[~2012-11-13 22:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-25 11:10 ali_anwar
2012-10-30  6:20 ` Yao Qi
2012-10-30 11:53   ` ali_anwar
2012-11-02 10:28     ` ali_anwar
2012-11-02 11:47       ` Yao Qi
2012-11-02 12:24     ` ali_anwar
2012-11-02 16:15   ` dje
2012-11-02 18:47     ` ali_anwar
2012-11-09 19:31       ` Anwar, Ali
2012-11-09 19:42         ` Pedro Alves
2012-11-09 19:48       ` Pedro Alves
2012-11-09 23:00         ` Luis Machado
2012-11-09 23:02           ` Luis Machado
2012-11-13 21:57           ` Tom Tromey
2012-11-13 22:23             ` Luis Machado [this message]
2012-11-14 18:29               ` Pedro Alves
2012-11-15 21:23                 ` Tom Tromey

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=50A2C88B.6070105@codesourcery.com \
    --to=lgustavo@codesourcery.com \
    --cc=ali_anwar@codesourcery.com \
    --cc=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=tromey@redhat.com \
    --cc=vladimir@codesourcery.com \
    --cc=yao@codesourcery.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