From: Pedro Alves <pedro@codesourcery.com>
To: Stan Shebs <stan@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: tracing broken if target doesn't do disconnected tracing
Date: Wed, 07 Apr 2010 13:47:00 -0000 [thread overview]
Message-ID: <201004071447.22727.pedro@codesourcery.com> (raw)
In-Reply-To: <4BBC8981.4050900@codesourcery.com>
On Wednesday 07 April 2010 14:32:49, Stan Shebs wrote:
> Pedro Alves wrote:
> > The support for the feature is reported by qSupported, hence it's
> > certainly target-wide noawadays. It may or not be desirable to
> > be able to select which processes keep tracing on disconnect, so
> > a per-status state flag for that also sounds acceptable --- it
> > could represent whether tracing will continue for a given process
> > after disconnection. The flag (trace_status->disconnected_tracing)
> > being 0 doesn't mean the target doesn't support disconnected
> > tracing, so there's still no way for the common code to know it.
> >
>
> In a way, what the user wants to know is what qSupported reports,
> dressed up in a reasonable fashion. Our traditional expectation has
> been the user knows already, because, well, it's the user's program and
> the user's hardware. But as the target gets more elaborate - and
> tracepoint support is certainly a quantum jump in that direction :-) -
> that assumption breaks down. In that vein, you may recall that one of
> our upcoming enhancements is to attach an arbitrary text string to a
> trace run, with the intended purpose of including things like a name and
> phone number, so that someone else connecting to the target can have a
> way to find out about the trace run, and know whether it's OK to mess
> with it.
I missed your point here. My point was that supporting disconnect
tracing or not seems to want to be target-wide feature, and that hence,
it should probably me exposed to common code as a target method (e.g.,
target_supports_disconnected_tracing). This, independent of a given
process/trace status saying that tracing will continue on detach
for a given run. So, common code could do things like:
if (current_trace_status ()->running
&& !current_trace_status ()->disconnected_tracing
&& target_supports_disconnected_tracing ())
{
int cont = query (_("Trace is running. Continue tracing after foo?")));
send_disconnected_tracing_value (cont);
}
and also in common code:
static void
set_disconnected_tracing (char *args, int from_tty,
struct cmd_list_element *c)
{
if (target_supports_disconnected_tracing ()
&& disconnected_tracing)
send_disconnected_tracing_value (disconnected_tracing);
else if (disconnected_tracing)
{
error/warn ("Target doesn't do disconnected tracing");
}
}
Instead of hacking it in remote.c, way late.
--
Pedro Alves
next prev parent reply other threads:[~2010-04-07 13:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-05 0:01 Pedro Alves
2010-04-05 1:08 ` Stan Shebs
2010-04-05 11:04 ` Pedro Alves
2010-04-07 1:34 ` Stan Shebs
2010-04-07 11:40 ` Pedro Alves
2010-04-07 13:33 ` Stan Shebs
2010-04-07 13:47 ` Pedro Alves [this message]
2010-04-07 14:07 ` Pedro Alves
2010-04-07 20:21 ` Stan Shebs
2010-04-07 22:06 ` Pedro Alves
2010-04-07 13:35 ` Pedro Alves
2010-04-07 22:04 ` Stan Shebs
2010-04-08 17:25 ` Pedro Alves
2010-04-08 18:19 ` Stan Shebs
2010-04-08 18:32 ` Pedro Alves
2010-04-08 19:10 ` Stan Shebs
2010-04-09 3:10 ` Stan Shebs
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=201004071447.22727.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=stan@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