From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-43476-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 5485 invoked by alias); 1 Apr 2006 16:39:21 -0000
Received: (qmail 5477 invoked by uid 22791); 1 Apr 2006 16:39:20 -0000
X-Spam-Check-By: sourceware.org
Received: from b.mail.sonic.net (HELO b.mail.sonic.net) (64.142.19.5)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 01 Apr 2006 16:39:18 +0000
Received: from snyder (209-204-172-156.dsl.static.sonic.net [209.204.172.156]) 	by b.mail.sonic.net (8.13.6/8.13.3) with SMTP id k31Gd5P1011862; 	Sat, 1 Apr 2006 08:39:05 -0800
Message-ID: <000901c655aa$78832620$677ba8c0@sonic.net>
Reply-To: "Michael Snyder" <msnyder@sonic.net>
From: "Michael Snyder" <msnyder@sonic.net>
To: <gdb-patches@sources.redhat.com>
Cc: <eliz@gnu.org>
Subject: Re: [RFA] Reverse debugging, part 1/3: target interface
Date: Sat, 01 Apr 2006 16:39:00 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2006-04/txt/msg00005.txt.bz2


Eli writes:
>> + /* Forward/reverse execution direction.
>> +    These will only be implemented by a target that supports reverse
execution.
>> + */
>> + #define target_get_execution_direction() \
>> +     (current_target.to_get_execdir ? \
>> +      (*current_target.to_get_execdir) () : EXEC_ERROR)
>
> Isn't it better if the default will be EXEC_FORWARD, not EXEC_ERROR?

Well, I wanted a way to probe and find out whether the target
implements these methods at all.  If you call get_execdir and
get back "error", you can report "sorry, this target doesn't support it".

I can see your argument, that you could simply report "yes,
you're going forward" -- but then the only way to probe
would be to call target_SET_execdir, and that seems too
intrusive for a probe.

Of course, I could just add a third target vector element,
but that seemed like overkill.  Perhaps I'm trying to be
too clever?

>> + /* Reverse execution.
>> +    FIXME: set up as a capability.  */
>> + static enum exec_direction_kind remote_execdir = EXEC_FORWARD;
>> +
>> + static enum exec_direction_kind remote_get_execdir (void)
>> + {
>> +   if (remote_debug && info_verbose)
>> +     printf_filtered ("remote execdir is %s\n",
>> +        remote_execdir == EXEC_FORWARD ? "forward" :
>> +        remote_execdir == EXEC_REVERSE ? "reverse" :
>> +        "unknown");
>> +   return remote_execdir;
>> + }
>> +
>> + static int remote_set_execdir (enum exec_direction_kind dir)
>> + {
>> +   if (remote_debug && info_verbose)
>> +     printf_filtered ("Set remote execdir: %s\n",
>> +        dir == EXEC_FORWARD ? "forward" :
>> +        dir == EXEC_REVERSE ? "reverse" :
>> +        "bad direction");
>> +
>> +   /* FIXME: check target for capability.  */
>> +   if (dir == EXEC_FORWARD || dir == EXEC_REVERSE)
>> +     return (remote_execdir = dir);
>> +   else
>> +     return EXEC_ERROR;
>> + }
>
> I don't understand these two methods--they don't seem to do anything
> that their names imply.  What am I missing?

It's deceptively simple.   ;-)

The two methods just get and set the value of a local mode variable,
remote_execdir.  That's all.  Then that variable is used by remote_wait
and remote_resume.