This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

--
Yao (éå)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]