Re: SOFTWARE_SINGLE_STEP_P and multi-arch

[jtc@redback.com (J.T. Conklin)]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> At present there are two macros that control software stepping:
Andrew>
Andrew> 	SOFTWARE_SINGLE_STEP_P()
Andrew>
Andrew> and 	SOFTWARE_SINGLE_STEP(sig, insert_or_remove)
Andrew>
Andrew> I'd like to suggest the following:
Andrew>
Andrew> Rename SOFTWARE_SINGLE_STEP_P() to TARGET_SOFTWARE_SINGLE_STEP_P() and
Andrew> add it to the *target* vector.


You're correct that hardware single step support is target dependent.
For example, SOFTWARE_SINGLE_STEP_P is 1 on the sparc (and thus the
embedded sparc varients like the sparclite and sparclet), but single
step performance using the remote protocol would be greatly improved
if the stub managed the step internally.  While not strictly a hard-
ware single step, it acts more or less the same.  Perhaps the names
SOFTWARE_SINGLE_STEP_P and SOFTWARE_SINGLE_STEP() should be changed
to something more appropriate?  I can't think of anything off hand.

One concern I have is that it may not be known whether a target
supports "hardware" single step until it is attempts one.  Using the
above examples of the sparclite and sparclet, older stubs won't have
support for the step command packet.  I can't think of a good way to
determine ahead of time whether the packet is supported.  GDB won't
know whether it's OK to use it until it's too late.

Perhaps this indicates we should be taking another approach.  This is
not completely thought out, feel free to shoot holes in it.  The step
function would be split out of target_resume() into a new vector
function target_step().  GDB would unconditionally call target_step(),
if it fails with an error code indicating that hardware single step is
not available, it would call SOFTWARE_SINGLE_STEP() and then
target_resume().

Looking at infrun.c:resume(), it looks like this wouldn't be a trivial
exercise. 

        --jtc

-- 
J.T. Conklin
RedBack Networks