[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

[Hui Zhu]

And what about this patch.  :)

http://sourceware.org/ml/gdb-patches/2012-01/msg01008.html

Thanks,
Hui

On 02/10/12 15:49, Hui Zhu wrote:
> Hi Pedro,
>
> What about my patch in
> http://sourceware.org/ml/gdb-patches/2012-01/msg01007.html ?
> It make tracepoint cannot be install before remote_get_trace_status.
> And after remote_get_trace_status, merge_uploaded_tracepoints can handle
> tracepoint.
>
> Best,
> Hui
>
> On 02/09/12 02:31, Pedro Alves wrote:
>> 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)?
>>
>