SOFTWARE_SINGLE_STEP_P and multi-arch

SOFTWARE_SINGLE_STEP_P and multi-arch

[Andrew Cagney]

Hello,

At present there are two macros that control software stepping:

	SOFTWARE_SINGLE_STEP_P()

and 	SOFTWARE_SINGLE_STEP(sig, insert_or_remove)

I'd like to suggest the following:

Rename SOFTWARE_SINGLE_STEP_P() to TARGET_SOFTWARE_SINGLE_STEP_P() and
add it to the *target* vector.

	Hardware single step support (implied
	by !TARGET_SOFTWARE_SINGLE_STEP_P())
	is target and not ISA/ABI dependant.

	Some ISAs might support hardware single
	step but the actual target may not
	(lousy OS support, limited stub functionality)

Make SOFTWARE_SINGLE_STEP Multi arch.
	(and I don't like it but I can't think
	of a better incremental move :-)

	While I think SOFTWARE_SINGLE_STEP()
	should be replaced by code that creates
	temp breakpoints and adds them to
	the breakpoint database (gdb would
	later pull them directly) I don't want
	to try and also do that.

	The way software single step is
	currently implemented is just ulgh...

Thoughts/comments?

	Andrew

Re: SOFTWARE_SINGLE_STEP_P and multi-arch

[Richard Earnshaw]

ac131313@cygnus.com said:
> Make SOFTWARE_SINGLE_STEP Multi arch.
> 	(and I don't like it but I can't think
> 	of a better incremental move :-)
> 	While I think SOFTWARE_SINGLE_STEP()
> 	should be replaced by code that creates
> 	temp breakpoints and adds them to
> 	the breakpoint database (gdb would
> 	later pull them directly) I don't want
> 	to try and also do that.
> 	The way software single step is
> 	currently implemented is just ulgh... 

It also doesn't work with INSTRUCTION_NULLIFIED, which is a pity, since on 
the ARM we really want both.

R.

Re: SOFTWARE_SINGLE_STEP_P and multi-arch

[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

Re: SOFTWARE_SINGLE_STEP_P and multi-arch

[Todd Whitesel]

Cleaning out my mailbox I discovered something from early December:

> 	Hardware single step support (implied
> 	by !TARGET_SOFTWARE_SINGLE_STEP_P())
> 	is target and not ISA/ABI dependant.
> 
> 	Some ISAs might support hardware single
> 	step but the actual target may not
> 	(lousy OS support, limited stub functionality)
...
> 	Andrew

I should also note that some ISAs might NOT support hardware single step
but the actual target DOES, because it is simulated in software by the
OS or stub.

All modern VxWorks targets support this, and step-range as well.
I expect that JTC's remote-wdb.c backend is using them.

Todd Whitesel
toddpw @ best.com

Re: SOFTWARE_SINGLE_STEP_P and multi-arch

[J.T. Conklin]

>>>>> "Todd" == Todd Whitesel <toddpw@best.com> writes:
Todd> Cleaning out my mailbox I discovered something from early December:
>> Hardware single step support (implied by
>> !TARGET_SOFTWARE_SINGLE_STEP_P()) is target and not ISA/ABI
>> dependant.
>> 
>> Some ISAs might support hardware single step but the actual target
>> may not (lousy OS support, limited stub functionality)

Todd> I should also note that some ISAs might NOT support hardware
Todd> single step but the actual target DOES, because it is simulated
Todd> in software by the OS or stub.

Indeed.  I think some of our existing targets assume "hardware" single
stepping when the ISA does not support it.  So far, we have been lucky
that all the ROM monitors, ICEs, and remote stubs emulate single step
on those targets.

At least as far as the remote protocol is concerned, a debug agent
SHOULD support the single step command.  If I could be assured that it
wouldn't break anything, I'd change that to a MUST.  The latency of
having GDB do software single step makes debugging unpleasant.

Todd> All modern VxWorks targets support this, and step-range as well.
Todd> I expect that JTC's remote-wdb.c backend is using them.

Indeed it does.

        --jtc

-- 
J.T. Conklin
RedBack Networks