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

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

[Frank Ch. Eigler]

Hi -

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.  This packet makes remote debugging
potentially significantly faster, because it can replace a sequence of
instruction single-step packets with just one new packet.  This finally
exercises J.T. Conklin's gdb-side extensions from roughly a year ago.

There is a gdb bug that is exposed by this support.  If a breakpoint
placed on the current instruction, and another one on the next
source line, then letting gdb "step" will stop at the next line, but
won't let gdb realize that the second breakpoint was hit.  (This is
because gdb never inserted the breakpoints in gdb/infrun.c's proceed(),
being unaware that remote_resume() meant something other than stepi.)
This looks like this is a minor problem, but just in case, support for
the packet may be forced off from the gdb side and/or from the sid side.

- FChE

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

[Andrew Cagney]

> Hi -
> 
> 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.  This packet makes remote debugging
> potentially significantly faster, because it can replace a sequence of
> instruction single-step packets with just one new packet.  This finally
> exercises J.T. Conklin's gdb-side extensions from roughly a year ago.
> 
> There is a gdb bug that is exposed by this support.  If a breakpoint
> placed on the current instruction, and another one on the next
> source line, then letting gdb "step" will stop at the next line, but
> won't let gdb realize that the second breakpoint was hit.  (This is
> because gdb never inserted the breakpoints in gdb/infrun.c's proceed(),
> being unaware that remote_resume() meant something other than stepi.)
> This looks like this is a minor problem, but just in case, support for
> the packet may be forced off from the gdb side and/or from the sid side.


Just to be clear.  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.

Andrew

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

[Frank Ch. Eigler]

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.

- FChE

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

[Andrew Cagney]

> 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

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

[Michael Snyder]

"Frank Ch. Eigler" wrote:
> 
> 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.

If the 'e' packet is going to change gdb's behavior while debugging
threads, this needs to be discussed and considered.  It may amount to
a bug in the specification of the 'e' packet.

And in fact, given the behavior that you describe in your first message, 
the 'e' packet _is_ going to change gdb's behavior while debugging
threads.

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

[Michael Snyder]

"Frank Ch. Eigler" wrote:
> 
> Hi -
> 
> 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.  This packet makes remote debugging
> potentially significantly faster, because it can replace a sequence of
> instruction single-step packets with just one new packet.  This finally
> exercises J.T. Conklin's gdb-side extensions from roughly a year ago.
> 
> There is a gdb bug that is exposed by this support.  If a breakpoint
> placed on the current instruction, and another one on the next
> source line, then letting gdb "step" will stop at the next line, but
> won't let gdb realize that the second breakpoint was hit.  (This is
> because gdb never inserted the breakpoints in gdb/infrun.c's proceed(),
> being unaware that remote_resume() meant something other than stepi.)
> This looks like this is a minor problem, but just in case, support for
> the packet may be forced off from the gdb side and/or from the sid side.

Thanks for pointing out this problem, which is in fact
more severe than you think.

A quick experiment reveals that if you 
  1) put a breakpoint at the beginning of line N
  2) put a second breakpoint in the MIDDLE of line N
  3) attempt to step over line N
the second breakpoint will not be hit.

And in fact, if you have a multi-threaded program, 
all threads will have the opportunity to run (if they
are runnable), and NONE of them will hit ANY breakpoints
while we are executing line N.  This will give threads
the opportunity to "run away".

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

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 937 bytes --]

Hi -

msnyder wrote:
> [...]
> Thanks for pointing out this problem, which is in fact
> more severe than you think.
> 
> A quick experiment reveals that if you 
>   1) put a breakpoint at the beginning of line N
>   2) put a second breakpoint in the MIDDLE of line N
>   3) attempt to step over line N
> the second breakpoint will not be hit.

Interesting, but at least it's an unusual debugging
usage scenario.


> And in fact, if you have a multi-threaded program, 
> all threads will have the opportunity to run (if they
> are runnable), and NONE of them will hit ANY breakpoints
> while we are executing line N.  This will give threads
> the opportunity to "run away".

No, I think that's only if the other threads all happen also
to be executing the same line N.  If any passes outside, then
the step-out-of-range process would abort, as the 'e' packet
is no more thread-specific than 's' is.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]