[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
Yao Qi
yao@codesourcery.com
Tue Jan 31 16:49:00 GMT 2012
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 (é½å°§)
More information about the Gdb-patches
mailing list