Re: remote protocol extension for step out of range

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> I'm wondering about is how this works in a threaded
Andrew> environment.  This continuation is very thread unfriendly (so
Andrew> is the underlying code so I'm fighting an up hill battle here
Andrew> :-).  That was the reason for thinking of an explicit
Andrew> breakpoint packet - so it could eventually be bound to a
Andrew> specific thread.  Given that this packet is mostly reflecting
Andrew> the way the GDB works, I suspect doing this different is
Andrew> beyond the scope of your proposed change.

From the protocol perspective, I don't think it would work any
differently than stepping or continuing a given task.  Currently
remote_resume() will send a "set thread" packet if the target's
current thread is different than GDB's.  I didn't change this for 
the new packets, so the debug agent will be able to determine what
thread the step range is for.

[ As your probably can recall from previous discussions, I would have
preferred to have an (optional) thread id in the new commands so that
the latency of an additional command to set the thread id could be 
avoided.  But that is inconsistant with the protocol architecture. ]

Both before and after this change, the protocol seems to be more
flexible than either GDB or the provided debug agents offer.  It
appears that GDB assumes that all threads are stopped when attached,
etc.  And none of the sample stubs have thread support at all.  IMO,
getting the protocol right is the most important, because both GDB and
the agents can grow into the capabilities of the protocol.

Andrew> How will this packet work with something like the sparc where,
Andrew> to do a correct continue you need to set both PC and NPC.
Andrew> Consequently a sparc does a resume by setting PC/NPC with
Andrew> register-write packets and then does the continue.

In a target that supported with threads, GDB would be setting the
thread specific PC and NPC, and the step, continue, and step over
range commands would act on the that thread.  One has to assume that
the step boundries for step over range would be stored in thread 
local memory.  When that thread is scheduled, the debug agent would 
catch the exception after one instruction had executed.   For step
over range, it would compare the PC with the step boundries.  If it
was within that range, it would reschedule the thread so it would do
another step.  Once it's out of range, it would send a notification
packet indicating that that thread has stopped.

Andrew> With regard to the syntax, can it be specified in a way that
Andrew> is extensable?  The ``T'' reply packet can bundle up all sorts
Andrew> of information.  If we're going to have a new continue packet
Andrew> can the syntax be such that it allows similar extensions?

I think we can make it extensible.  The fact that the proposed packets
return status makes it lot easier than otherwise.  If we define status
for errors more stringently than has been done in the past, GDB should 
be able to probe for extensions reasonably well.

However, other than thread ID, I'm at a bit of a loss about what more
we would want to add.

        --jtc

-- 
J.T. Conklin
RedBack Networks