[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]

On 02/10/12 15:54, Hui Zhu wrote:
> And what about this patch. :)
>
> http://sourceware.org/ml/gdb-patches/2012-01/msg01008.html
>
> Thanks,
> Hui
>

Ping.

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)?
>>>
>>
>