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

[Hui Zhu <hui_zhu at mentor dot com>]

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