From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19937 invoked by alias); 8 Feb 2012 18:31:49 -0000 Received: (qmail 19923 invoked by uid 22791); 8 Feb 2012 18:31:47 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 08 Feb 2012 18:31:31 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q18IVOpu032330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Feb 2012 13:31:25 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q18IVMJL024443; Wed, 8 Feb 2012 13:31:23 -0500 Message-ID: <4F32BF7A.4000900@redhat.com> Date: Wed, 08 Feb 2012 18:31:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: Yao Qi CC: Hui Zhu , gdb-patches@sourceware.org Subject: 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 References: <4F274C42.7010008@mentor.com> <4F27A4AD.9020608@codesourcery.com> In-Reply-To: <4F27A4AD.9020608@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-02/txt/msg00107.txt.bz2 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