From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28741 invoked by alias); 3 Sep 2012 15:32:07 -0000 Received: (qmail 28730 invoked by uid 22791); 3 Sep 2012 15:32:05 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_CP,TW_QT,TW_TF X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Sep 2012 15:31:35 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1T8Ycg-0003vD-5m from Yao_Qi@mentor.com for gdb-patches@sourceware.org; Mon, 03 Sep 2012 08:31:34 -0700 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Sep 2012 08:31:34 -0700 Received: from qiyao.dyndns.org.dyndns.org (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.1.289.1; Mon, 3 Sep 2012 08:31:32 -0700 From: Yao Qi To: Subject: [PATCH] Fix a bug on uploading tsv Date: Mon, 03 Sep 2012 15:32:00 -0000 Message-ID: <1346686250-17361-1-git-send-email-yao@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes 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-09/txt/msg00019.txt.bz2 Hi, When writing a test case to 'tsv changed notification', I find when GDB re-connects (connects again after disconnect) to remote target, only one tsv is uploaded, and the rest tsv in target are not uploaded. This patch is to fix this bug. This patch is to remove incorrectly checking condition '!cur_tpoint' in function cmd_qtsv. cur_tpoint is set to non-NULL after calling cmd_qtfp, that is to say, target tracepoints are uploaded to GDB. However, we upload TSV first and upload tracepoints second in GDB, as we can see in remote.c:remote_start_remote, /* Possibly the target has been engaged in a trace run started previously; find out where things are at. */ if (remote_get_trace_status (current_trace_status ()) != -1) { struct uploaded_tp *uploaded_tps = NULL; struct uploaded_tsv *uploaded_tsvs = NULL; if (current_trace_status ()->running) printf_filtered (_("Trace is already running on the target.\n")); /* Get trace state variables first, they may be checked when parsing uploaded commands. */ remote_upload_trace_state_variables (&uploaded_tsvs); merge_uploaded_trace_state_variables (&uploaded_tsvs); remote_upload_tracepoints (&uploaded_tps); merge_uploaded_tracepoints (&uploaded_tps); } So it is wrong to check condition '!cur_tpoint' because 'cur_tpoint' is always NULL when calling cmd_qtsv, and we should remove it. Regression tested on x86_64-linux. OK? gdb/gdbserver: 2012-09-03 Yao Qi * tracepoint.c (cmd_qtsv): Adjust debug message. Remove an incorrect condition checking. --- gdb/gdbserver/tracepoint.c | 10 ++-------- 1 files changed, 2 insertions(+), 8 deletions(-) diff --git a/gdb/gdbserver/tracepoint.c b/gdb/gdbserver/tracepoint.c index 9d62bb6..3e0a7ce 100644 --- a/gdb/gdbserver/tracepoint.c +++ b/gdb/gdbserver/tracepoint.c @@ -3873,15 +3873,9 @@ cmd_qtfv (char *packet) static void cmd_qtsv (char *packet) { - trace_debug ("Returning first trace state variable definition"); + trace_debug ("Returning additional trace state variable definition"); - if (!cur_tpoint) - { - /* This case would normally never occur, but be prepared for - GDB misbehavior. */ - strcpy (packet, "l"); - } - else if (cur_tsv) + if (cur_tsv) { cur_tsv = cur_tsv->next; if (cur_tsv) -- 1.7.7.6