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

[Pedro Alves <palves at redhat dot com>]

On 01/31/2012 08:22 AM, Yao Qi wrote:
> Patch attached is used to illustrate my thought to fix this problem.  I
> am not confident on it because I don't know it is correct to change the
> order of function calls in remote_start_remote.  The "non stop" path in
> remote_start_remote is not affected by this patch.  In the "stop" path,
> the order of some functions call is changed, but don't know they are
> equivalent.
> 
>    Original                            Patched
> 
>    start_remote                  merge_uploaded_tracepoints
>    remote_check_symbols          start_remote
>    merge_uploaded_tracepoints    remote_check_symbols

The tracepoints module depends on remote_check_symbols (qSymbols), in
order to detect the IPA is loaded, and so that anything related
to fast tracepoints works.  On the other hand, if there are already
fast tracepoints on the target, then the qSymbols business must have
already have been done in the previous time gdb was connected.

I don't think we're okay with this in non-stop mode though.  We should
relocate our symbols before we try to merge tracepoints.  Yet, we need to
merge tracepoints before any breakpoint re-set.  Thing is in non-stop mode,
you find new inferiors and possibly do re-sets early in remote_start_remote
(find threads -> remote_notice_new_inferior -> notice_new_inferior can do a lot
behind the scenes).

It may be simpler and safer to just have a way for update_global_location_list
to know that it shouldn't try to install tracepoints yet (cause we're still going
through startup)?

-- 
Pedro Alves