question on trace-stop-notes implementation

question on trace-stop-notes implementation

[Dmitry Kozlov]

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?

Thank you,
Dmitry

Re: question on trace-stop-notes implementation

[Stan Shebs]

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

Re: question on trace-stop-notes implementation

[Yao Qi]

On 10/03/2012 08:46 PM, Dmitry Kozlov wrote:
> This provides difficulties for IDE integration: for exampe IDE can't
> know that stop notes changed without explicit quering gdb by show
> stop-notes.

A new MI notification 'command param changed' was added to GDB CVS
mainline some weeks ago, and MI frontend should get the notification 
when stop note is changed by 'set trace-stop-notes' command.

(gdb)
set trace-stop-notes bar
&"set trace-stop-notes bar\n"
=cmd-param-changed,param="trace-stop-notes",value="bar"
^done

This notification (along with other notifications I added recently) is 
to address the difficulties you mentioned (MI frontend has to query GDB 
to get some states of GDB).

-- 
Yao

Re: question on trace-stop-notes implementation

[Prus, Vladimir]

Does that work if we connect to a target that has tracing in progress, with some end note already set?

- Volodya

On 07.10.2012, at 12:00, "Yao Qi" <yao@codesourcery.com> wrote:

> On 10/03/2012 08:46 PM, Dmitry Kozlov wrote:
>> This provides difficulties for IDE integration: for exampe IDE can't
>> know that stop notes changed without explicit quering gdb by show
>> stop-notes.
> 
> A new MI notification 'command param changed' was added to GDB CVS
> mainline some weeks ago, and MI frontend should get the notification when stop note is changed by 'set trace-stop-notes' command.
> 
> (gdb)
> set trace-stop-notes bar
> &"set trace-stop-notes bar\n"
> =cmd-param-changed,param="trace-stop-notes",value="bar"
> ^done
> 
> This notification (along with other notifications I added recently) is to address the difficulties you mentioned (MI frontend has to query GDB to get some states of GDB).
> 
> -- 
> Yao

Re: question on trace-stop-notes implementation

[Yao Qi]

On 10/08/2012 01:26 AM, Prus, Vladimir wrote:
> Does that work if we connect to a target that has tracing in progress, with some end note already set?

Yes, I think so.  Command parameter change notification is emitted 
whenever command parameter is changed, it has nothing to do with other 
factors.

The session below is about what you want, IIUC,

(gdb)
set trace-stop-notes foo
&"set trace-stop-notes foo\n"
=cmd-param-changed,param="trace-stop-notes",value="foo"
^done 
 

(gdb) 
 

tstart
&"tstart\n"
=tracepoint-downloaded,id="1",address="0x080483ca"\n
^done
(gdb)
set trace-stop-notes bar
&"set trace-stop-notes bar\n"
=cmd-param-changed,param="trace-stop-notes",value="bar"
^done

-- 
Yao

Re: question on trace-stop-notes implementation

[Pedro Alves]

On 10/08/2012 01:56 AM, Yao Qi wrote:
> On 10/08/2012 01:26 AM, Prus, Vladimir wrote:
>> Does that work if we connect to a target that has tracing in progress, with some end note already set?
> 
> Yes, I think so.  Command parameter change notification is emitted whenever command parameter is changed, it has nothing to do with other factors.
> The session below is about what you want, IIUC,

I don't think that's the same issue.  If you connect to a target that already had
tracing on progress, you'd want to read the stop note that was already set on the
target.  There's no way currently.  With RSP notifications, and MI change notifications
in place, you'd still miss a way to sync the stop note on initial connection.

-- 
Pedro Alves

Re: question on trace-stop-notes implementation

[Yao Qi]

On 10/17/2012 12:38 AM, Pedro Alves wrote:
> On 10/08/2012 01:56 AM, Yao Qi wrote:
>> On 10/08/2012 01:26 AM, Prus, Vladimir wrote:
>>> Does that work if we connect to a target that has tracing in progress, with some end note already set?
>>
>> Yes, I think so.  Command parameter change notification is emitted whenever command parameter is changed, it has nothing to do with other factors.
>> The session below is about what you want, IIUC,
>
> I don't think that's the same issue.  If you connect to a target that already had
> tracing on progress, you'd want to read the stop note that was already set on the
> target.  There's no way currently.  With RSP notifications, and MI change notifications
> in place, you'd still miss a way to sync the stop note on initial connection.
>

I misunderstood "that work" in the original question.

-- 
Yao