This is the mail archive of the
mailing list for the GDB project.
Re: sid debugger interface extension: step out-of-range packet support
> 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).
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.