From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2969 invoked by alias); 20 Apr 2006 23:53:37 -0000 Received: (qmail 2958 invoked by uid 22791); 20 Apr 2006 23:53:37 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Apr 2006 23:53:35 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k3KNrXsu031871; Thu, 20 Apr 2006 19:53:33 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k3KNrXKg008509; Thu, 20 Apr 2006 19:53:33 -0400 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k3KNrUTq031730; Thu, 20 Apr 2006 19:53:31 -0400 Message-ID: <44481EF9.5010900@redhat.com> Date: Thu, 20 Apr 2006 23:53:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) MIME-Version: 1.0 To: Daniel Jacobowitz CC: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [RFA] Reverse debugging, part 1/3: target interface References: <442DAA70.5070203@redhat.com> <444426C7.6020604@redhat.com> <20060418125836.GB10130@nevyn.them.org> <20060418152443.GA13825@nevyn.them.org> <44456356.8090706@redhat.com> <444680C3.1010007@redhat.com> <20060420134343.GC11710@nevyn.them.org> <4447DF7D.6070506@redhat.com> <20060420195047.GA22563@nevyn.them.org> In-Reply-To: <20060420195047.GA22563@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00303.txt.bz2 Daniel Jacobowitz wrote: > With that fixed I can try it: > > (gdb) tar rem :1234 > Remote debugging using :1234 > 0x00002aaaaaaaba80 in ?? () > (gdb) rsi > 0x00002aaaaaaaba80 in ?? () > (gdb) > 0x00002aaaaaaaba83 in ?? () > > OK, that's two bugs. One is the vCont bug I mentioned in another > message; it's stepping forward instead of backwards. The other has > nothing to do with this at all; apparently PTRACE_STEP isn't working > for the first instruction in the program and we're taking two steps to > go one instruction. OK, let's avoid the vCont bug and try again: > > (gdb) set remote verbose-resume-packet 0 > (gdb) rsi > Sending packet: $m2aaaaaab7320,1#70...Ack > Packet received: f3 > Sending packet: $M2aaaaaab7320,1:cc#50...Ack > Packet received: OK > Sending packet: $Hc0#db...Ack > Packet received: E01 > Sending packet: $bs#d5...Ack > Packet received: > warning: Invalid remote reply: > *hang* > > It thinks that the attempt to step has succeeded and that the program > is now running. That's pretty messy failing. Agreed, of course. Well, this code in remote_wait... 1.1 (shebs 16-Apr-99): default: 1.1 (shebs 16-Apr-99): warning ("Invalid remote reply: %s", buf); 1.1 (shebs 16-Apr-99): continue; 1.1 (shebs 16-Apr-99): } *... has been essentially untouched since the public repository was created. I could trace it back further, but my gut feeling is that it is basically untested. I mean, if we say "continue" here, of course it's going to hang... we've just consumed the target's reply, so it's not going to send us anything else. Generally, you send one command, you get one reply. My inclination is to call error here, instead of continue. But of course I know of no way to test the effects, except for the experiment you've just done. How does that strike you? * Of course the code is not really Stan's -- he just created the repository.