[PATCH 0/5] MI notification on trace started/stopped (V3)

[Yao Qi <yao@codesourcery.com>]

Hello,
This patch series adds the MI notifications of 'trace-started' and
'trace-stopped', which are emitted when

  1) trace is started or stopped by commands in GDB,
  2) trace is stopped due to some reasons in the remote stub, such as
trace buffer full.

With these notifications, MI front-end can show the status of trace
up to date.

Patch 4/5 is to address #1, adding new MI notifications and
notifying observers when the commands are called.  #2 needs more work
here, because GDB doesn't know the trace is stopped in the remote
stub.  So we need an async remote notification 'Trace' to tell GDB.
That is what patch 3/5 about.  Patch 5/5 is to use this async remote
notification 'Trace' and notify trace_changed observer.

Patch 1/5 and 2/5 are the enhancement to the async remote
notification, which is needed by the rest of patches in this series.
Patch 1/5 adds "annex" for notification, which is helpful 1) to give
more information on each event of notification, 2) to query supported
notifications on "annex" level.  Patch 2/5 teaches both GDB and
GDBserver to query supported notifications and annexes in the other
side so that 1) GDBserver doesn't send notifications that GDB doesn't
understand, 2) GDB doesn't have to fetch status from the GDBserver if
a certain notification is supported by GDBserver.

This patch series is the V3 of this series.  V2 was posted
<http://sourceware.org/ml/gdb-patches/2012-12/msg00687.html>.  Here
are some changes in V3,

  - Introduce query mechanism on supported notifications
  - Introduce concept "annex" into remote notification,
  - Remove trace notes in MI notifications, suggested by Pedro in the
    review.
  - Combine observers 'trace-started' and 'trace-stoped' into one
    observer 'trace-changed'.

Each patch is tested cumulatively on x86_64-linux with the combination
{unix, native-gdbserver} x {sync, async}.  Is it OK?

-- 
1.7.7.6