From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15103 invoked by alias); 20 Aug 2009 15:03:01 -0000 Received: (qmail 14992 invoked by uid 22791); 20 Aug 2009 15:03:00 -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 mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 Aug 2009 15:02:53 +0000 Received: (qmail 23568 invoked from network); 20 Aug 2009 15:02:51 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 Aug 2009 15:02:51 -0000 From: Pedro Alves To: Hui Zhu Subject: Re: gdb reverse execution: how to actually run tests for it? Date: Thu, 20 Aug 2009 17:10:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb@sourceware.org, Jakob Engblom References: <002001ca1f0e$4c9b74a0$e5d25de0$@com> <200908171255.28644.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200908201602.50138.pedro@codesourcery.com> 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-08/txt/msg00200.txt.bz2 On Monday 17 August 2009 16:31:19, Hui Zhu wrote: > > How bad is the failure mode in the reverse tests if the target > > does not support reverse at all? =A0Can't we try a simple > > probing-for-support reverse test and if that fails skip the > > rest of the reverse tests? =A0That would likely get rid of all > > the current needs for a hacked board file. > > > > -- > > Pedro Alves > > >=20 > It will be very helpful. >=20 > If the target don't support reverse, =A0it will out like: > (gdb) rc > Target child does not support this command. That's a native target ("child"). I don't think you'll get that error currently against *remote* targets. Looking at remote.c:remote_resum= e, I think a reverse-continue command against gdbserver will end up sending a regular forward-direction "vCont" packet, so the remote inferior will execute *forward* instead of reverse...=20 Oh well, it's easy to try. Here it goes: $./gdbserver :9999 ./gdbserver ./gdb ./gdbserver/gdbserver (gdb) tar remote :9999 (gdb) b main (gdb) c 1884 char **next_arg =3D &argv[1]; (gdb) reverse-step 1885 int multi_mode =3D 0; If you disable the vCont packet, with "set remote verbose-resume-packet off= ", then GDB will indeed send the correct back-step or back-continue ("bs"/"bc") packets, but, those will be ignored by gdbserver... You'll end up with a broken debug session if you try this: 1884 char **next_arg =3D &argv[1]; (gdb) set remote verbose-resume-packet off (gdb) reverse-step warning: Invalid remote reply: Interrupted while waiting for the program. Give up (and stop debugging it)? (y or n) ... It's really much better if the target reports support or not upfront, so that GDB doesn't even *try* anything reverse if the target does not support it. --=20 Pedro Alves