From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22427 invoked by alias); 1 Apr 2014 12:48:53 -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 22415 invoked by uid 89); 1 Apr 2014 12:48:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 01 Apr 2014 12:48:52 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1WUy7U-0003Hv-ED from Yao_Qi@mentor.com ; Tue, 01 Apr 2014 05:48:48 -0700 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Apr 2014 05:48:48 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.2.247.3; Tue, 1 Apr 2014 05:48:47 -0700 Message-ID: <533AB531.6040607@codesourcery.com> Date: Tue, 01 Apr 2014 12:48:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Pedro Alves CC: Subject: Re: [PATCH] Fix several "set remote foo-packet on/off" commands. References: <1396307414-2053-1-git-send-email-palves@redhat.com> <533A7E83.4070200@codesourcery.com> <533AABE1.8040101@redhat.com> In-Reply-To: <533AABE1.8040101@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00008.txt.bz2 On 04/01/2014 08:06 PM, Pedro Alves wrote: > As part of that project, we'll definitely need to move the > whole remote_protocol_packets global array to remote_state. > This global array already exists. I've just moved a few more manually > managed flags into this array. Note this is listed as a TODO in > the MultiTarget project's wiki page. > Therefore, I'm not really adding any conflict, as that work will > already have to be done. When that is done, we'll likely end up > with passing a 'struct remote_state *' pointer to the new packet_support > function. And with that in mind, it just looks like unnecessary > churn to remove the parameter from remote_multi_process_p now (and > update all callers), only to add it back again. Do you agree? > Yes, that is fine to keep unused parameter 'rs' remote_multi_process_p. >> > Not sure it is part >> > of your plan to convert the global state to per-target state. > I don't plan to work on it myself in the near future, but it's > definitely the way to go. > OK, got it. >>> >> + >>> >> + # Force-disable the InstallInTrace RSP feature. >>> >> + gdb_test_no_output "set remote install-in-trace-packet off" >>> >> + >>> >> + # Set a tracepoint while a trace experiment is ongoing. >>> >> + set test "set tracepoint on set_tracepoint" >>> >> + gdb_test_multiple "${trace_type} set_tracepoint" $test { >>> >> + -re "Target returns error code .* too far .*$gdb_prompt $" { >>> >> + if [string equal $trace_type "ftrace"] { >>> >> + # The target was unable to install the fast tracepoint >>> >> + # (e.g., jump pad too far from tracepoint). >>> >> + pass "$test (too far)" >> > >> > A nit here, a fast tracepoint is not installed due to "jump pad too far" >> > instead of "set remote install-in-trace-packet off". Do we want to emit >> > a PASS here? > Oh, hmm. Copy-paste from the other function in the file, and I > just didn't think about that part much. It actually makes no sense > to even expect that the target sends back any error code. We've just > disabled installing tracepoints while a trace experiment is running, > so we shouldn't see any response from the target at all. > >> > IMO, UNSUPPORTED is better. > Agreed, though note you made this a PASS in tracepoint_change_loc_1. ;-) > Sorry about that :) patch v2 looks good to me. -- Yao (齐尧)