From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9676 invoked by alias); 20 Jan 2009 18:22:27 -0000 Received: (qmail 9668 invoked by uid 22791); 20 Jan 2009 18:22:26 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_50,SPF_PASS X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Jan 2009 18:22:19 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n0KIRYRN009047; Tue, 20 Jan 2009 12:27:37 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 12:22:12 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: reverse for GDB/MI Date: Tue, 20 Jan 2009 18:22:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA06CB06BB@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <001401c96dce$5609c060$021d4120$@com> References: <49463870.6080302@virtutech.com> <494A0A9C.6020809@virtutech.com> <494B5A82.4020004@virtutech.com> <494BF080.9060009@vmware.com> <6D19CA8D71C89C43A057926FE0D4ADAA06B06B04@ecamlmw720.eamcs.ericsson.se> <001401c96dce$5609c060$021d4120$@com> From: "Marc Khouzam" To: "Jakob Engblom" , 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-01/txt/msg00427.txt.bz2 Hi, I am hoping this request can help restart the process of getting the reverse MI commands approved. I have applied the patches of Process Record and Replay and have built myself a nice GDB that can do reverse debugging on Linux. I then implemented the corresponding support in DSF-GDB=20 (soon to be committed.) However, I ran into some MI limitations (explanation below for those interested) which make me need=20 the MI Commands for Reverse debugging. A patch for these commands was submitted in http://sourceware.org/ml/gdb-patches/2008-12/msg00276.html but there were many discussions after, which did not seem to conclude.=20 The details of my troubles follow: With no MI commands for Reverse I tried to use CLI commands but ran into a bug causing incomplete MI *stopped event when using CLI comm= ands. http://sourceware.org/ml/gdb/2008-12/msg00058.html As per Nick's finding, I tried Async mode to work around *stopped event bug= but realized Process Record and Replay does not support Async. So, the solution I currently have is to use "set execution-direction" and t= he MI commands for execution. For example, to perform a 'reverse-continue' fr= om DSF-GDB I have to do the set of three commands: set execution-direction reverse -exec-continue set execution-direction forward It would be nice to have the reverse MI commands :-) Thanks Marc > -----Original Message----- > From: gdb-patches-owner@sourceware.org=20 > [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Jakob Engblom > Sent: Saturday, January 03, 2009 1:09 PM > To: gdb-patches@sources.redhat.com > Subject: RE: reverse for GDB/MI >=20 >=20=20 > > Hi, > >=20 > > It was pointed out to me that people who have been doing reversible > > debug for a while seems to > > have specific commands for reverse debugging and they do=20 > have a command > > for "go to time point P". > > For example http://www.undo-software.com/undodb_man.html: > >=20 > > bgoton > > Move forwards or backwards to the specified time, in simulated > > nanoseconds. > > bgoton + | - > > Step forward/backward the specified number of simulated nanoseconds. >=20 > Simics has it to, in some different ways: >=20 > skip-to =20 > reverse n time units > continue n time units >=20 > I think this is a good example of the kind of new commands=20 > and abilities that > come with having a reverse ability in the first place, like=20 > Marc said.=20 >=20 > And as the later discussion evolved, it would be jolly nice=20 > to have an idea of > time in gdb. I think that is needed anyway to handle=20 > multicore, multiprocessor, > and multithreaded debug: when things happen in disparate=20 > locations under the > control of a single debugger quickly gets very interesting... >=20 > Best regards, >=20 > /jakob >=20 > _______________________________________________________ >=20 > Jakob Engblom, PhD, Technical Marketing Manager >=20 > Virtutech Direct: +46 8 690 07 47=20=20=20=20 > Drottningholmsv=E4gen 14 Mobile: +46 709 242 646=20=20=20 > 11243 Stockholm Web: www.virtutech.com=20=20 > Sweden > ________________________________________________________ >=20=20 >=20 >=20 >=20