From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3299 invoked by alias); 12 Jul 2009 19:26:14 -0000 Received: (qmail 3290 invoked by uid 22791); 12 Jul 2009 19:26:13 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 12 Jul 2009 19:26:08 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n6CJPQv9008141; Sun, 12 Jul 2009 14:25:26 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Jul 2009 14:25:12 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Testing of reverse debug commands Date: Sun, 12 Jul 2009 19:26:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA07B71A3E@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <200907122007.38248.pedro@codesourcery.com> References: <4A5930EE.3040201@vmware.com> <4A5A19FC.9050206@vmware.com> <6D19CA8D71C89C43A057926FE0D4ADAA07B71A36@ecamlmw720.eamcs.ericsson.se> <200907122007.38248.pedro@codesourcery.com> From: "Marc Khouzam" To: "Pedro Alves" , Cc: "Michael Snyder" , "Jan Kratochvil" , "Joel Brobecker" , "Hui Zhu" X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-07/txt/msg00085.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:pedro@codesourcery.com]=20 > Sent: July-12-09 3:08 PM > To: gdb@sourceware.org > Cc: Marc Khouzam; Michael Snyder; Jan Kratochvil; Joel=20 > Brobecker; Hui Zhu > Subject: Re: Testing of reverse debug commands >=20 > On Sunday 12 July 2009 19:49:58, Marc Khouzam wrote: >=20 > > From a frontend perspective, the current 'record' command=20 > is not very > > good. >=20 > > First, there is no MI equivalent, although that is not a big deal. > > But since it does not report error, the frontend must always assumes > > that > > the command worked. >=20 > Are you sure that is the case with "record"? I see `error' calls > in record.c:record_open. If there are some missing, let's add them. As usual you are right. :-) (gdb) record &"record\n" &"Process record target can't debug inferior in asynchronous mode (target-async).\n" ^error,msg=3D"Process record target can't debug inferior in asynchronous mode (target-async)." (gdb)=20 I had made the assumption that 'record stop' was the same as 'record'. > > Below you can see that using 'record stop' directly will=20 > give a ^done > > instead of an ^error when it fails (although there is an=20 > error message > > but we don't parse those in Eclipse). Also, using -interpreter-exec > > is even worse as even the error message is gone. >=20 > Note that "record stop" is really a different command, although > it shares a common "record" prefix. >=20 > >=20 > > (gdb)=20 > > record stop > > &"record stop\n" > > ~"Process record is not started.\n" > > ^done > > (gdb)=20 >=20 > > So, I think some improvement would be nice for frontends. >=20 > So, is this really an error? Hui seems to have thought > it wasn't. Hui? If it is, then it's just a matter of > changing the corresponding printf_unfiltered calls in > record.c to `error' calls (look for the "Process record=20 > is..." string). > Then MI will get an ^error,msg=3D"foo", instead of a ~"foo" + ^done. That would be more consistent for a frontend. The frontend can then decide if this should be reported as an error or simply accepted. But that is not such a big deal anymore, now that you pointed out 'record' itself does report an error. Thanks Marc