Re: [PATCH] Disconnected tracing

[Michael Snyder <msnyder@vmware.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!   ;-)