From: Stan Shebs <stanshebs@earthlink.net>
To: Dmitry Kozlov <dmitry_kozlov@mentor.com>
Cc: gdb@sourceware.org, Vladimir Prus <vladimir@codesourcery.com>,
Luis Machado <luis_gustavo@mentor.com>,
"'Stan_Shebs@mentor.com'" <Stan_Shebs@mentor.com>,
Marc Khouzam <marc.khouzam@ericsson.com>
Subject: Re: question on trace-stop-notes implementation
Date: Wed, 03 Oct 2012 20:14:00 -0000 [thread overview]
Message-ID: <506C9C7D.50806@earthlink.net> (raw)
In-Reply-To: <506C3395.8010701@mentor.com>
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
next prev parent reply other threads:[~2012-10-03 20:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-03 12:46 Dmitry Kozlov
2012-10-03 20:14 ` Stan Shebs [this message]
2012-10-07 8:00 ` Yao Qi
2012-10-07 17:26 ` Prus, Vladimir
2012-10-08 0:57 ` Yao Qi
2012-10-16 16:38 ` Pedro Alves
2012-10-17 1:16 ` Yao Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=506C9C7D.50806@earthlink.net \
--to=stanshebs@earthlink.net \
--cc=Stan_Shebs@mentor.com \
--cc=dmitry_kozlov@mentor.com \
--cc=gdb@sourceware.org \
--cc=luis_gustavo@mentor.com \
--cc=marc.khouzam@ericsson.com \
--cc=vladimir@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).