Re: remote protocol extension for step out of range

Re: remote protocol extension for step out of range

[Andrew Cagney]

> I think we can poke a similar hole in GDB as it stands today.  For
> instance, GDB does a step out of range for thread T1.  Without the
> step out of range command, it does it internally by issuing multiple
> steps and comparing the PC after each step.  While this is happening,
> thread T2 hits a breakpoint and returns status that T2 has stopped.
> The user then does a step out of range for T2.
> 
> I think the problem is the same, and will only be solved when GDB
> is able to track multiple processes/threads/contexts.

That is what I want to be 100% clear on.

It means that there is probably going to be an interum version of this
feature - one that works with the current thread model.  This discussion
thread [er, groan] should provide the rationale behind the decision :-)

Enjoy,
	Andrew

Re: remote protocol extension for step out of range

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> I think we can poke a similar hole in GDB as it stands today.  For
>> instance, GDB does a step out of range for thread T1.  Without the
>> step out of range command, it does it internally by issuing multiple
>> steps and comparing the PC after each step.  While this is happening,
>> thread T2 hits a breakpoint and returns status that T2 has stopped.
>> The user then does a step out of range for T2.
>> 
>> I think the problem is the same, and will only be solved when GDB
>> is able to track multiple processes/threads/contexts.

Andrew> That is what I want to be 100% clear on.
Andrew>
Andrew> It means that there is probably going to be an interum version
Andrew> of this feature - one that works with the current thread
Andrew> model.  This discussion thread [er, groan] should provide the
Andrew> rationale behind the decision :-)

I think it's more like this feature will always work in a single
threaded context, and because of current limitations within GDB will
"mostly" work in a multi-threaded context.  It will fail if there is a
context switch in the middle of a step over range.  This same failure
can occur without the step-over-range command when GDB issues multiple
step-instruction commands and explicitly checks the pc to determine if
it is in range.  This problem will be addressed when GDB is enhanced
to keep track of each execution context.

I believe the protocol command itself is solid and won't need updating.

If debug agents are written correctly, they will store the step ranges
in thread specific instead of global variables.  So they will not have
to be updated.  IMO there is a risk here.  It would be best if we had
a reference implementation, but as of yet we don't have a sample debug
agent that supports threads.  Something to address in the future.  For
the time being, it might be acceptable to mention this in the remote
protocol section of the GDB User's manual.

Is there anything else you think must be addressed?  I'd like to make
sure you're comfortable with this before going forward.  On the other
hand, I'd like to get this in because it makes debugging so much nicer
over high latency links.

        --jtc

-- 
J.T. Conklin
RedBack Networks