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: [PATCH] Fix error when gdb connect to a stub that tracepoint is running[1/2] reset current_trace_status in the begin of remote_start_remote


On 01/31/2012 07:26 PM, Hui Zhu wrote:
> I have 2 ideas with your mail:
> 1. If we want move merge_uploaded_tracepoints (&uploaded_tps); to the
> begin, I think all the code about tracepoint should move to the begin of
> this function.
> 
>   /* Possibly the target has been engaged in a trace run started
>      previously; find out where things are at.  */
>   if (remote_get_trace_status (current_trace_status ()) != -1)
>     {
>       struct uploaded_tp *uploaded_tps = NULL;
>       struct uploaded_tsv *uploaded_tsvs = NULL;
> 
>       if (current_trace_status ()->running)
>     printf_filtered (_("Trace is already running on the target.\n"));
> 
>       /* Get trace state variables first, they may be checked when
>      parsing uploaded commands.  */
> 
>       remote_upload_trace_state_variables (&uploaded_tsvs);
> 
>       merge_uploaded_trace_state_variables (&uploaded_tsvs);
> 
>       remote_upload_tracepoints (&uploaded_tps);
> 
>       merge_uploaded_tracepoints (&uploaded_tps);
>     }
> 

Yes, that is what I did in my patch.  They should be moved as a whole.

> 2.  But I think move the code before start_remote is not very well.
> Because the code before tracepoint code do a lot of init work, maybe
> move it will bring more issues to current code.

Changing the order of code in a large function (remote_start_remote)
makes me feel a little uncomfortable.  I'll think of it carefully.

-- 
Yao (éå)


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