The current GDBRemoteCommunication::ReadPacket() support
for notifications is very limited. Notably, it can return notifications
when the caller does not expect them and it does not provide an explicit
API to distinguish them from standard packets. This is not a major
problem right now, as we force serialization when running in non-stop
mode and can predict when we expect notifications to arrive.
Firstly, add an explicit 'allow_notification' parameter to ReadPacket()
and WaitForPacketNoLock(). When it is false (the default),
notifications are pushed onto a queue rather than returned
to the caller. Effectively, the existing callers can now safely expect
the reading functions to return only standard responses,
and the non-stop logic can explicitly permit notifications.
Secondly, add an explicit PacketResult value for notifications. This
value can only be returned when allow_notification is true, so it does
not require changes for most of the callers. For the few that support
notifications, it makes it possible to distinguish standard packets
from notification packets.
Update the non-stop client code to take advantage of the new API,
and therefore be more strict when dealing with responses in non-stop
Sponsored by: The FreeBSD Foundation