From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8752 invoked by alias); 24 Jun 2011 08:47:59 -0000 Received: (qmail 8742 invoked by uid 22791); 24 Jun 2011 08:47:58 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-fx0-f41.google.com (HELO mail-fx0-f41.google.com) (209.85.161.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 24 Jun 2011 08:47:39 +0000 Received: by fxm18 with SMTP id 18so2158989fxm.0 for ; Fri, 24 Jun 2011 01:47:38 -0700 (PDT) Received: by 10.223.61.134 with SMTP id t6mr4076585fah.28.1308905258085; Fri, 24 Jun 2011 01:47:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.29.155 with HTTP; Fri, 24 Jun 2011 01:46:58 -0700 (PDT) From: Hui Zhu Date: Fri, 24 Jun 2011 08:47:00 -0000 Message-ID: Subject: [RFA/tracepoint] Make GDB can work with some old GDB server To: gdb-patches ml Content-Type: text/plain; charset=ISO-8859-1 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: 2011-06/txt/msg00368.txt.bz2 Hi, I got some bug report about ppa in https://lkml.org/lkml/2011/6/4/65 It is: kgdb_breakpoint () at kernel/kgdb.c:1721 1721 wmb(); /* Sync point after breakpoint */ Sending packet: $qSymbol::#5b...Ack Packet received: Packet qSymbol (symbol-lookup) is NOT supported Sending packet: $qTStatus#49...Ack Packet received: E22 trace API error 0x2. (gdb) bt No stack. (gdb) This is because this kgdb(I think trunk have fixed this bug) don't support qtstatus and reply -0x22. So gdb throw a error. Then all connect process stop. This is a bug of kgdb, but I think make gdb just output a warning is not affect anything else. So I make this patch. Please help me review it. Thanks, Hui 2011-06-24 Hui Zhu * remote.c (remote_start_remote): Add TRY_CATCH for remote_get_trace_status. * tracepoint.c (disconnect_tracing): Ditto. --- remote.c | 13 ++++++++++++- tracepoint.c | 14 +++++++++++++- 2 files changed, 25 insertions(+), 2 deletions(-) --- a/remote.c +++ b/remote.c @@ -3146,6 +3146,8 @@ remote_start_remote (int from_tty, struc struct remote_state *rs = get_remote_state (); struct packet_config *noack_config; char *wait_status = NULL; + int ret = 0; + volatile struct gdb_exception ex; immediate_quit++; /* Allow user to interrupt it. */ @@ -3389,7 +3391,16 @@ remote_start_remote (int from_tty, struc /* 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) + TRY_CATCH (ex, RETURN_MASK_ERROR) + { + ret = remote_get_trace_status (current_trace_status ()); + } + if (ex.reason < 0) + { + warning(_("%s"), ex.message); + ret = -1; + } + if (ret != -1) { struct uploaded_tp *uploaded_tps = NULL; struct uploaded_tsv *uploaded_tsvs = NULL; --- a/tracepoint.c +++ b/tracepoint.c @@ -1939,11 +1939,23 @@ trace_status_mi (int on_stop) void disconnect_tracing (int from_tty) { + int ret = 0; + volatile struct gdb_exception ex; + /* It can happen that the target that was tracing went away on its own, and we didn't notice. Get a status update, and if the current target doesn't even do tracing, then assume it's not running anymore. */ - if (target_get_trace_status (current_trace_status ()) < 0) + TRY_CATCH (ex, RETURN_MASK_ERROR) + { + ret = target_get_trace_status (current_trace_status ()); + } + if (ex.reason < 0) + { + warning(_("%s"), ex.message); + ret = -1; + } + if (ret < 0) current_trace_status ()->running = 0; /* If running interactively, give the user the option to cancel and