Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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