No support for hardware single step in gdb?

[Peter Reilley]

I am adding support for the Motorola 8260 chip to GDB.   This
will use the 8260 JTAG interface and a Macraigor Kestrel box.   I am
having a problem where the 8260 hangs when you single step
over a breakpoint.   

The single step process in GDB inserts all breakpoints before
doing an istep.   In the 8260 the breakpoint instruction is an
illegal opcode which causes a trap.   Unfortunately, if the 
breakpoint is inserted immediately before the current PC then
the 8260 will single step onto an illegal instruction.   This
hangs the 8260.   The 8260 has a hardware single step available
that is used by the Kestrel JTAG box.

I can solve this problem by calling remove_breakpoints() before
the single step and then calling insert_breakpoints after the single
step.   This is a complete waste since I am just undoing what
GDB has just done before calling me.   Inserting and removing
the breakpoints 4 times can have an impact on speed since
they go out over the Kestrel JTAG interface to access memory.

A much better solution would be if there were a way of allowing
the target code to control whether breakpoints were inserted before
executing a single step.

This problem is seen in the 8260 chip only.   I have the IBM 403 chip
working OK with the current way of handling istep.   On the
8260 it seems that the instruction queue has already read the 
breakpoint instruction from memory and restoring the original
instruction to memory does not cause the queue to be flushed
and the correct data to be read.

It seems to me that adding a #ifdef to the proceed() routine
in infrun.c would be the cleanest way to handle this.

Any thoughts?
Pete.