From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5299 invoked by alias); 7 Sep 2009 22:33:06 -0000 Received: (qmail 5290 invoked by uid 22791); 7 Sep 2009 22:33:06 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_22,SARE_SUB_OBFU_Q1,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Sep 2009 22:32:57 +0000 Received: (qmail 9083 invoked from network); 7 Sep 2009 22:32:55 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 7 Sep 2009 22:32:55 -0000 From: Pedro Alves To: Michael Snyder Subject: Re: [PATCH] Add 'reverse' capability query to remote protocol (qSupported). Date: Mon, 07 Sep 2009 22:33:00 -0000 User-Agent: KMail/1.9.10 Cc: Eli Zaretskii , "gdb-patches@sourceware.org" , "jakob@virtutech.com" , "glaw@undo-software.com" References: <4A9C2AD3.5070904@vmware.com> <4AA586A3.20907@vmware.com> <4AA586DD.4030805@vmware.com> In-Reply-To: <4AA586DD.4030805@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909072332.55193.pedro@codesourcery.com> 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: 2009-09/txt/msg00176.txt.bz2 On Monday 07 September 2009 23:19:09, Michael Snyder wrote: > Michael Snyder wrote: > > Pedro Alves wrote: > >> What about the i18n comments? > > > > Oof, sorry, forgot. You just mean the two error msgs, right? > > See revised diff. Yep. Thanks. > >> What about the vCont (the one about not sending vcont > >> if requesting a reverse resume) comments? > > > > Are you sure? I guess, like you, I hoped it would eventually > > be added. Works fine as it is, it probes and fails, but if > > you want it, ok... added below. That's because your target doesn't support vCont, otherwise, the target will run forward instead of backwards. Granted, the target_can_support_reverse check at a higher layer will prevent getting here if neither bc or bs are supported, but, there may be targets that end up supporting both (forward) vCont and bs+bc. > > I have one final question to raise. > > > > You may notice (though nobody has commented), that I made the > > two new supported-probed-packets (bs and bc) default to "enabled". > > > > This sort of defeats the purpose (if the purpose is that we can > > decide whether to run a testsuite on a remote target) -- but I > > was just reluctant to default them to "disabled", because it > > would mean that anybody with a deployed target that doesn't yet > > support the new "qSupported" probe would have to make his users > > enable them by hand. > > > > (why I cc:ed Jakob and Greg.) > > > > So now that I've mentioned it, what do you think? > > Enabled, or disabled by default? > Oh, I totally missed that. When would they be set to disabled without user intervention then? E.g., what happens against current gdbserver? Does it still misbehave when trying to reverse step? Given there's an easy workaround (set remote foo-packet on), I vote disabled by default. -- Pedro Alves