From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41142 invoked by alias); 12 Sep 2015 18:01:48 -0000 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 Received: (qmail 41132 invoked by uid 89); 12 Sep 2015 18:01:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f174.google.com Received: from mail-yk0-f174.google.com (HELO mail-yk0-f174.google.com) (209.85.160.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 12 Sep 2015 18:01:46 +0000 Received: by ykdt18 with SMTP id t18so99780818ykd.3 for ; Sat, 12 Sep 2015 11:01:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.170.136.67 with SMTP id d64mr5139996ykc.103.1442080904410; Sat, 12 Sep 2015 11:01:44 -0700 (PDT) Received: by 10.129.111.6 with HTTP; Sat, 12 Sep 2015 11:01:44 -0700 (PDT) In-Reply-To: References: <1441074040-65069-1-git-send-email-cole945@gmail.com> <86si6wyg43.fsf@gmail.com> Date: Sat, 12 Sep 2015 18:01:00 -0000 Message-ID: Subject: Re: [PATCH 1/2 v2] Re-check fastpoint after reloading symbols. From: Wei-cheng Wang To: Yao Qi Cc: Ulrich Weigand , gdb-patches@sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-09/txt/msg00264.txt.bz2 Hi Yao, Thank you for looking into this. https://sourceware.org/ml/gdb-patches/2015-06/msg00589.html Ulrich suggested me to check whether the fast tracepoint is valid on GDB si= de. However, if it returns false, it will cause an internal error in remote_download_tracepoint. And this patch is for that issue. As you said in previous mail. If it's not right to check the validity based on the assumption of where the jumppad is. Maybe it should always return 'yes' for powerpc in ppc_fast_tracepoint_valid_at (or simply use default_fast_tracepoint_valid_at) Any suggestion, Ulrich? Thanks, Wei-cheng On Sun, Sep 13, 2015 at 1:31 AM, Wei-cheng Wang wrote: > Hi Yao, > > Thank you for looking into this. > > https://sourceware.org/ml/gdb-patches/2015-06/msg00589.html > Ulrich suggested me to check whether the fast tracepoint is valid on GDB > side. > However, if it returns false, it will cause an internal error in > remote_download_tracepoint. > > As you said in previous mail. If it's not right to check the validity ba= sed > on the assumption of > where the jumppad is. Maybe it should always return 'yes' for powerpc in > ppc_fast_tracepoint_valid_at > (or simply use default_fast_tracepoint_valid_at) > > Any suggestion, Ulrich? > > Thanks, > Wei-cheng > > > On Wed, Sep 2, 2015 at 11:51 PM, Yao Qi wrote: >> >> Wei-cheng Wang writes: >> >> Hi Wei-cheng, >> >> > I just realized that disabled tracepoints will still be downloaded >> > on the target by 'tstart' command, and they can be re-enabled (by >> > QTEnable packet) when trace is running, so I cannot simply disable >> > an invalid tracepoint to prevent invalid tracepoint being downloaded. >> > >> > Scenario 1: the trace is not running. >> > >> > Because all tracepoints will be downloaded, when 'tstart', it doesn't >> > matter whether they are disabled or not. I think if any invalid >> > tracepoint is found, simply throw an error to force user to delete >> > invalid tracepoint. >> > >> > Scenario 2: the trace is already running. >> > >> > I think the check should be placed before update_global_location_list, >> > because it will try to download new tracepoints on target. >> > (download_tracepoint_locations). update_breakpoint_locations will not >> > download disabled tracepoints, so we should disable invalid tracepoints >> > before calling update_global_location_list. >> > (see: should_be_inserted in download_tracepoint_locations) >> > >> > Otherwise, if we don't disable invalid tracepoints, an error is thrown, >> > and the program will stop at _dl_debug_state. Then the user has to >> > delete >> > the tracepoint manually to continue the execution. >> > >> > If a pending tracepoint is resovled after trace is running, and the us= er >> > tries to enable an invalid tracepoint after , server will report an >> > error that it is not installed. It won't run into internal error. >> > >> > Any suggestion? >> >> I didn't follow your previous tracepoint patches, so I don't understand >> what problem are you trying to fix in this patch. Nowadays, GDB sends >> fast tracepoint to GDBserver, if GDBserver can't install it (jump pad is >> too far from tracepoint), GDBserver will return error, and GDB knows >> about it. Do you want to do the check in GDB side rather than GDBserver >> side? >> >> -- >> Yao (=E9=BD=90=E5=B0=A7) > >