Re: sid debugger interface extension: step out-of-range packet support

[Andrew Cagney <ac131313@cygnus.com>]

> 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:
> <http://sources.redhat.com/ml/gdb/2001-02/msg00054.html> ?  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