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


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



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