[RCF 0/4] A general notification in GDB RSP

[Yao Qi <yao@codesourcery.com>]

Hi,
We have more and more requirements that remote target wants to notify
GDB via RSP at any time during connection when some states are changed
in remote target.  However, GDB doesn't have such general notification
infrastructure.  This is what this patch set tries to add.

Nowadays, notification mechanism exists in GDB for '%Stop' only,
and works pretty good.  My rationale of this work is 'decouple
%Stop/vStopped from existing notification mechanism so that
notification mechanism can handle other types of notification.

First of all, let us look at how '%Stop' and 'vStopped' works,

    gdb           gdbserver
        <- %Stop         // [1] Send notification
       [after process other packets]
        -> vStopped      // [2] Ack this notification
        <- T05 thread:2  // [3] Reply
        -> vStopped      // [4] Continue to query
        <- OK            // [5] Done

We can generalize this protocol like this,

    gdb           gdbserver
        <- %NOTIF         // [1] Send notification
       [after process other packets]
        -> vACK           // [2] Ack this notification
        <- REPLY          // [3] Reply
        -> vACK           // [4] Continue to query
        <- OK             // [5] Done

For each type of notification, we only have to define three things,

   1) NOTIF, the key word of notification, for example, "Stop"
   2) ACK, the command GDB ack to this notification, "vStopped" for
example,
   3) REPLY, the format of reply to GDB.  GDBserver should be able to
send packet to comply with REPLY, and GDB is able parse the packet,
and identify the packet is REPLY or not.

Patch 1/4 is to create a general queue data structure which will not
only be used in patch 2/4 and 3/4, but also can be used in elsewhere
in GDB.
The patch 2/4 and 3/4 are to decouple %Stop and vStopped out of
existing notification, in order to make notification more general.
Patch 4/4 is to demonstrate how do we add a new type of notification
in the future, and test two types of notification work good
together.  As you can see, it is relatively simple.  Originally, I
intended to convert qTstatus to a new type of notification in patch
4/4 as an example (when tracing status is changed, GDBserver sends
notification), but it takes time to think about it, so I post this
version here to get feedbacks first.

All three patches are tested on x86_64-linux {native, gdbserver} x
{sync, async}.  No regression.

Note that the behaviour of notification in RSP is unchanged, that is
to say, patched GDB (w/ patch 2/4) works well with unpatched
GDBserver, and patched GDBserver (w/ patch 3/4) works well with
unpatched GDB.

it is different from Hui's patch 3/9 in 'autload breakpoint'
patch series,

  [RFC] Autoload-breakpoints new version [3/9] notification async
  http://sourceware.org/ml/gdb-patches/2012-08/msg00214.html

His patch is to teach GDB to handle notification at anytime, while
mine is not, but to allow to add other types of notification similar
to existing %Stop/vStopped on the same infrastructure.