From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6039 invoked by alias); 29 Apr 2006 00:37:35 -0000 Received: (qmail 6029 invoked by uid 22791); 29 Apr 2006 00:37:35 -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; Sat, 29 Apr 2006 00:37:33 +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 k3T0bVOc019538; Fri, 28 Apr 2006 20:37:31 -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 k3T0bU9B024783; Fri, 28 Apr 2006 20:37:30 -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 k3T0bTtt001138; Fri, 28 Apr 2006 20:37:29 -0400 Message-ID: <4452B548.7030502@redhat.com> Date: Sat, 29 Apr 2006 00:37: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 3/3: user interface / docs References: <442DAAD9.6080509@redhat.com> <44442877.1060401@redhat.com> <20060420160717.GF11710@nevyn.them.org> <44481117.8070904@redhat.com> <20060424204705.GA27220@nevyn.them.org> In-Reply-To: <20060424204705.GA27220@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/msg00380.txt.bz2 Daniel Jacobowitz wrote: > On Thu, Apr 20, 2006 at 03:54:15PM -0700, Michael Snyder wrote: > >>Daniel Jacobowitz wrote: >> >>>FWIW, I've got no opinions on this patch. The content looks fine. My >>>only concern is that I don't much like "set" variables which succeed or >>>fail depending on the target - we can switch targets unexpectedly. >>> >>>Can we just give the error in proceed if the target can't run in >>>reverse? >> >>You mean, "and not give an error when you say "set exec-dir"? >> >>Well here's the thing: I've had experience with something >>very similar*, and the users complained. They wanted to >>know sooner if there was a problem. >> >>* Tracepoints. You don't find out that the remote target can't >>support them until you say continue. > > > Sorry about the delay; I started replying to this on Thursday but > didn't finish it before I headed out for a long weekend. My turn to appologize. Been implementing some of your other suggestions. > I agree that, as user interface, this is unpleasant. But here's some > of the other cases we have to consider. > > (gdb) set exec-dir reverse > (gdb) target remote :1234 > > -> Should it work before you're connected? To my present way of thinking, no. It's target dependent, it can't work before you set the target. There are other commands that won't work without a target, notably "run" (except in the native case), or "info threads". > (gdb) target remote :1234 > (gdb) set exec-dir reverse > (gdb) disconnect > (gdb) run > > -> Where do we get the error now? We've switched targets, "run" can't > go in reverse for target child. Well, there you've got me. That's a problem. > > And as we've already seen, your error doesn't actually come at the > right time, since your remote protocol doesn't have a probe packet! > So remote will always let it succeed and child will always make it > fail, regardless of whether the remote target actually supports it. > > That's mighty inconsistent. I'm open to suggestions on a more > consistent way to present the problem. I'm stumped -- I can think of only two approaches: 1) add a probe packet, or 2) throw out the "set exec-dir" user interface (just use "rs" etc.). I don't like to throw out the user interface without a fight, 'cause I find it a fairly intuitive interface. So... maybe this forces us to add a probe?