Re: [PATCH v4 0/5] MI notification on trace started/stopped

[Yao Qi <yao@codesourcery.com>]

On 04/02/2013 10:31 AM, Yao Qi wrote:
> Hi,
> The V3.1 can't be applied to CVS trunk clearly, so I resolved these
> conflicts and submit them again.
>
> All doc bits were approved by Eli in V3.1.  Regression tested them
> on x86_64-linux with {unix, native-gdbserver} x {sync, async}.  Is
> it OK?  Below is the introduction of this series.  People who are
> familiar with this series, please skip it.
>
> 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.

Ping.  http://sourceware.org/ml/gdb-patches/2013-04/msg00019.html

-- 
Yao (齐尧)