Re: question on trace-stop-notes implementation

[Stan Shebs <stanshebs at earthlink dot net>]

On 10/3/12 5:46 AM, Dmitry Kozlov wrote:
> Hello,
> I noticed that trace-stop-notes being set by set trace-stop-notes 
> command are not shown in trace status until tracing is actually 
> stopped by tstop command. Similar start notes (set by set trace-notes 
> command) are shown every time in trace status. This provides 
> difficulties for IDE integration: for exampe IDE can't know that stop 
> notes changed without explicit quering gdb by show stop-notes. From 
> IDE prospective it is easier and more consistent to show stop notes in 
> separate field in trace status output, just like this is done for 
> start notes.
> Are there any objections if I fix it?

As the manual suggests, the set command mostly exists so that you can 
fix up or expand on a stop note that was supplied with tstop. Tracing 
running semi-autonomously as it does, you may find yourself typing the 
tstop command (or hitting a stop button) rather hastily, and only after 
that would you realize that maybe you ought to add some more 
explanation, contact info, etc, particularly if you just stopped 
somebody else's trace run.

I considered making the set command finicky and not even allow it until 
after a trace run is stopped, but that seemed excessive, plus it seemed 
like there might be use cases where a script might want to pre-set for 
some reason.

It seems like it would be massively confusing to ever display a stop 
note before the trace actually stopped; you'd have to do some linguistic 
gymnastics to explain the situation:

  the trace is still running, but if it were to stop, it would say 
"trace buffer filled up, choking the VM!", unless you had supplied a 
different argument to tstop

However, I don't see any problem with always supplying it in MI output; 
then it's up to the IDE to display in a clear way.

Stan
stan@codesourcery.com