Re: [PATCH] Disconnected tracing

[Michael Snyder <msnyder at vmware dot com>]

Stan Shebs wrote:
> Tom Tromey wrote:
> > > > > > > "Stan" == Stan Shebs <stan@codesourcery.com> writes:
> > > > > > >             
> > Stan> This next patch realizes a long-anticipated advantage of tracepoints,
> > Stan> namely that it should be possible to disconnect GDB from the target
> > Stan> but leave the trace experiment running, then reconnect later to see if
> > Stan> anything interesting turned up.
> >
> > A couple little nits...
> >
> > Stan> + extern void create_tracepoint_from_upload (int num, enum bptype type,
> > Stan> + 					   ULONGEST addr);
> >
> > Could this be in a header?  And then the declaration in
> > remote_get_tracing_state removed?
> >
> > Maybe this is another of those "will be fixed by the target vector"
> > oddities.
> >
> >   
> Yep, this is all going to get churned around by both target vector 
> changes and uploading rewrite.  With unified syntax, the uploading part 
> (qTfP/qTsP) is part of remote protocol, but the parsing of tracepoint 
> info fields gets to be generic.

This is all so cool!   ;-)