This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: tracing broken if target doesn't do disconnected tracing


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]