From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3247 invoked by alias); 13 Feb 2002 20:52:04 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 3147 invoked from network); 13 Feb 2002 20:52:01 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 13 Feb 2002 20:52:01 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 575113C8E; Wed, 13 Feb 2002 15:52:00 -0500 (EST) Message-ID: <3C6AD1EF.90003@cygnus.com> Date: Wed, 13 Feb 2002 12:52:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.8) Gecko/20020210 X-Accept-Language: en-us MIME-Version: 1.0 To: "Frank Ch. Eigler" Cc: cagney@redhat.com, sid@sources.redhat.com, gdb@sources.redhat.com Subject: Re: sid debugger interface extension: step out-of-range packet support References: <20020212171421.D13536@redhat.com> <3C6A0365.4050207@cygnus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-q1/txt/msg00034.txt.bz2 > cagney wrote: > > >> [...] > >> > A small amount of new code in sid/include and sid/component/gdb >> > now allows gdb's "step out-of-range" packet ('e'/'E') to work with >> > all sid-based simulator targets. [...] > >> >> [...] I wouldn't rely to much on that current packet and/or >> implementation. A number of issues with it have been pointed out >> with it. Suggest looking through the archives. > > > I did. Are you referring to a thread other than this one: > ? I must > admit I don't see the severity of that problem -- it sounds like the > user experience may be a little jarring with multithreaded apps, but > not inconsistent or lossy. One reference is (which came up with a search of cagney remote step). http://sources.redhat.com/ml/gdb/2001-05/msg00216.html A synopsis of my current view towards this code is as follows: The existing way that the step-range code is implemented in core GDB is unfortunate (it relies on global variables and global state.). If someone, while making changes to infrun.c, or the threading code in the process drops support for the current mechanism (with a new implementation only appearing as a vague a TODO item) I would agree to this. I consider the need to fix problems in infrun.c and threading to be far more important than this performance tune. remote.c is in a similar situtation. If someone were to offer code changing it to async (but not including the [eE] packet support) I would again be agreeable. In the case of the eE packets, the target interactioin is different to that of the [cC] and [sS] packets. Retaining them is clearly far more important then the [Ee]. I guess the best way of putting it is don't rely on this *specific* implementation of a step-out-of range mechanism to be around long term. I don't think it is fair, on my part, to be some how commiting future maintainers to the support of an esentially broken implementation. Sigh. enjoy, Andrew