From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14129 invoked by alias); 6 Oct 2008 21:20:05 -0000 Received: (qmail 14015 invoked by uid 22791); 6 Oct 2008 21:20:04 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 06 Oct 2008 21:19:19 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id A60852A00C; Mon, 6 Oct 2008 14:19:14 -0700 (PDT) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost2.vmware.com (Postfix) with ESMTP id 987148E5CA; Mon, 6 Oct 2008 14:19:14 -0700 (PDT) Message-ID: <48EA8065.9070001@vmware.com> Date: Mon, 06 Oct 2008 21:20:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Michael Snyder , Joel Brobecker , "gdb-patches@sourceware.org" , Pedro Alves , teawater Subject: Re: [RFA] Reverse Debugging, 1/5 References: <48E3CCB6.4060501@vmware.com> <20081006203021.GA21853@adacore.com> <48EA7C75.7070703@vmware.com> <20081006211131.GA26663@caradoc.them.org> In-Reply-To: <20081006211131.GA26663@caradoc.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-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00166.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Oct 06, 2008 at 02:00:37PM -0700, Michael Snyder wrote: >> It was a design choice. >> >> There were two choices: >> 1) modify target_resume (ops->to_resume), to add a direction >> parameter. >> 2) Add a to_set_direction target method. >> >> The first would have required modifying all existing targets, >> so I chose the second. > > The problem is, we're now talking about a multi-process GDB. It's a > small step from there to one using multiple targets automatically. Is > core GDB going to have to do the juggling / bookkeeping to keep > direction in sync for all of them? The granularity will depend on the > backend... > > If it's just a matter of changing the existing targets, then avoiding > that on a branch makes sense - but updating everything in the mainline > version makes sense too. I guess I could be persuaded. But I'm not, yet... You're going to send "to_set_direction" to the target, and then you're going to assume that you know what the state is later on, rather than asking the target? What if the target gets it wrong? Now you're out of sync. If we do keep the direction-state in the core, where would we put it? In the ecs? In a global variable in infrun? I still feel as if it's only the target that KNOWS what its direction state is -- it should tell gdb, rather than have gdb make assumptions.