This is the mail archive of the
mailing list for the GDB project.
Re: SOFTWARE_SINGLE_STEP_P and multi-arch
- To: Todd Whitesel <toddpw at best dot com>
- Subject: Re: SOFTWARE_SINGLE_STEP_P and multi-arch
- From: jtc at redback dot com (J.T. Conklin)
- Date: 21 Mar 2001 15:55:01 -0800
- Cc: ac131313 at cygnus dot com (Andrew Cagney), gdb at sourceware dot cygnus dot com
- References: <200103210951.BAA06932@shell17.ba.best.com>
- Reply-To: jtc at redback dot com
>>>>> "Todd" == Todd Whitesel <email@example.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
>> 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.