Re: [PATCH 5/7] Handle notification for all-stop.

[Pedro Alves <palves at redhat dot com>]

On 11/21/2012 04:19 AM, Yao Qi wrote:
> On 11/20/2012 02:21 AM, Pedro Alves wrote:
>>> In all-stop mode, notification packet will be parsed/handled in
>>> >'remote_wait_as',
>> AFAICS, handle_notification is called from both getpkt_or_notif_sane_1
>> and putpkt_binary.  Please explain_why_  we need to change
>> remote_wait_as.
> 
> It is a mistake to call handle_notification in remote_wait_as.  As you said, handle_notification is called from both getpkt_or_notif_sane_1
> and putpkt_binary.
> 
>>
>>> >so we define that all notifications have a prefix 'N'.
>> Hmm.  I don't follow.  How does "define that all notifications have
>> a prefix 'N'" follow from notifications being parsed by
>> remote_wait_as?  What's the real rationale for forcing an 'N' prefix?
>> We have "Stop" today, which doesn't start with N, and also
>> notifications are defined to start with '%'.  So what's with this 'N'?
>>
> 
> The original intention of this patch is to handle 'ctrl-c' in all-stop/async properly, to fix the following regression caused by my patch series.
> 
>   FAIL: gdb.threads/sigthread.exp: stop with control-c (the program exited)
> 
> Without my patch, after GDB sends 'vCont' to resume inferior, it goes back to event loop.  It is expected to get 'ctrl-c' or 'T' reply from remote.
> 
> With my patch, after GDB sends 'vCont' and back to event loop, GDB may get
>
> 'ctrl-c', 'T' reply from remote, or rsp notification.  Supposing GDB gets a rsp notification in event loop, GDB should handle
>
> this notification, and go back event loop again to get potential 'ctrl-c', 'T' reply and rsp notification.  We should
>
> replace 'getpkt_sane' with 'getpkt_or_notif_sane', as the first chunk of this patch does.  In 'remote_wait_as', we have to
>
> return if 'getpkt_or_notif_sane' gets a rsp notification, however, we can't tell that 'getpkt_or_notif_sane' gets a rsp
>
> notification or other packets.  So I propose that we give a prefix 'N' to all rsp notifications, so that we can differentiate them.
> 
> Maybe, we can give a different return value of 'getpkt_or_notif_sane', so that the caller can tell it gets a rsp notification or packets.

Yes, that'd be a much much better solution.  I think a new boolean
output parameter would be best.

-- 
Pedro Alves