[PATCH] Fix tracepoint tstart again get gdb_assert

[Yao Qi]

On 12/09/2011 10:33 PM, Pedro Alves wrote:
> I think this is overkill.  It's just impossible to be absolutely
> certain a trace run is currently ongoing.  If you do "tstatus;tstart",
> the trace can still stop between the two commands.  Is there

This is a very good example.

> anything that we benefit from clearing the inserted flag
> on tstatus?  I think that if we clear them only, and

No, I don't think we benefit from clearing `inserted' flag on tstatus.
The intention of patch v2 is trying to make gdb's trace status as closed
to remote stub's as possible.  Your example above prove that it may make
no sense.

> always, at "tstart" time, we're good.  We already clear all
> the inserted flag of all breakpoints and tracepoints on target
> open ("target remote ...", etc.), from within
> breakpoint.c:breakpoint_init_inferior -- that's why you don't
> see this assertion if you disconnect and reconnect, and find
> the target was tracing.
> 
> So I think we should just clear the inserted flag of all
> tracepoints in start_tracing, right after the target_trace_init
> call.  Possibly even merge the new loop with the existing loop
> that downloads tracepoints.

This sounds right, and makes patch quite simpler :)

-- 
Yao (齐尧)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-clear-inserted-flag.patch
Type: text/x-patch
Size: 717 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20111209/70276317/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-status-stop.patch
Type: text/x-patch
Size: 5529 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20111209/70276317/attachment-0001.bin>