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

[Pedro Alves]

On 08/24/2012 03:25 AM, Yao Qi wrote:
> 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.

I haven't read the patches in detail yet, but I'd like to say
upfront that I like this very much.

-- 
Pedro Alves